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(57) Recorded on the recording medium (BD-ROM) 
is an AV stream that is obtained by multiplexing a video 
stream and one or more audio streams. MOVIE objects 
are scenarios showing playback procedures of video 
data described using playback device-oriented com- 
mands. In addition to the MOVIE objects, enhanced- 
mode scenarios (Java and Web Page objects) are also 
recorded on the recording medium. These enhanced- 
mode scenarios, each of which is described in the Java 
language or a markup language, show control proce- 
dures with respect to playback devices. The Java and 
WebPage objects are capable of taking over register 
setting values set by MOVIE objects, and extracting 
parts of video data played by MOVIE objects. 
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Description 

Technical Field 

[0001] The present invention relates to a video-data 
recording medium such as Blu-Ray Disc Read Only 
Memory (hereinafter simply "BD-ROM"), a playback de- 
vice for playing such a recording medium, a program, a 
playback method, and a recording method, and in par- 
ticular relates to a technology of distributing movie 
works and the like by the recording medium. 

Background Art 

[0002] Distribution of movie works by recording media 
is an important source of revenue for movie-makers and 
suppliers. Video data of movie works is produced by get- 
ting celebrated actors cast in roles and a large amount 
of cost is spent for the production, and therefore, video 
data of movie works holds significant property values. It 
is considered now that enhancing the added value of 
such video data by using functions of recording media 
and playback devices makes quite meaningful sense 
with the objective of merchandise strategy in order to 
distribute movie works. One strategy to enhance the 
added value of DVDs is that, on DVDs where video data 
has been recorded, quizzes and games applying the 
video data are recorded so that users have fun with play- 
ing with these features. Even if the same video data has 
been used, a user gets dramatically different impres- 
sions of the video data when watching it as a movie and 
when seeing it as one scene of a corresponding game. 
While requiring a little work, this allows to keep convey- 
ing fresh impressions to a user, and therefore such an 
added value enhancement is a powerful weapon to 
moviemakers. 

[0003] The prior art relating to ways to enhance the 
added value of DVDs includes the known technology 
disclosed in the following Patent Reference 1. 

Patent Reference 1: Japanese Patent No. 2813245 

[0004] Conventionally, the added value enhancement 
has been realized by using renderable secondary imag- 
es (i.e. subtitles) and interpretable commands for DVD 
playback devices, in other words, such an added value 
enhancement is a by-product as a result of applying 
functions of playback devices. As networking of home 
appliances advances, the functions of playback devices 
are on the verge of dramatic evolution. With the ad- 
vancement of the networking, home appliances, such 
as a playback device, have started to include browsers 
and Java Virtual Machines as standard equipment and 
to be equipped with operation modes implemented by 
these browsers and Java Virtual Machines, which re- 
sults in supplying a user with various services through 
networks. In light of the advancement of playback de- 
vices, it is expected that movie suppliers will propose to 
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electric appliance makers to create new contents for en- 
hancing the added value of actual video data by har- 
nessing characteristic features of Java Virtual Machines 
and browsers. Although Java Virtual Machines and 
5 browsers have been in widespread use, a concept in 
which enhancing the added value of actual video data 
by using these applications has never existed so far. 
Even if there is such a demand, both kinds of playback 
devices, having and not having a Java Virtual Machine 
10 and a browser, will appear in the actual market for com- 
mercial electric appliances. If there is no operation as- 
surance when the added-value enhanced recording me- 
dium is loaded on a playback device not having these 
applications, then the recording medium may be reject- 
's ed from the market. 

[0005] In addition, when recording media with movie 
works recorded thereon are distributed, targeting play- 
back devices hooked up to home appliance networks, 
copyrights of the movie works will be exposed to un- 
20 known risk. Although operation modes using a Java Vir- 
tual Machine and a browser have an appeal, the un- 
known risk certainly makes the copyright holders deeply 
anxious. 



[0006] The present invention aims at offering a re- 
cording medium and a playback device capable of real- 
izing operation assurance for any type of playback de- 
30 vices while enhancing the added value of actual video 
data, in the case where a Java virtual Machine and a 
browser are equipped on the playback device, by using 
these applications. 

[0007] The above objective is achieved by a recording 

35 medium having video data, a plurality of programs, and 
a table recorded thereon, wherein each of the plurality 
of programs shows a playback control procedure of the 
video data; the table includes (1) identification informa- 
tion of each of the plurality of programs, and (2) infor- 

40 mation showing that each of the plurality of programs 
belongs to either a movie mode or an enhanced mode; 
one of the plurality of programs includes a command for 
branching; and the branching command specifies a 
branch destination using indirect referencing via the ta- 

45 ble. Using the command for branching enables to dy- 
namically switch over between playback of the video da- 
ta as a movie in the movie mode and controls in the en- 
hanced mode. In the case where the controls in the en- 
hanced mode are implemented by using a Java Virtual 

50 Machine and a browser, the video data recorded on the 
recording medium is played on either a screen for play- 
ing normal movies or a screen relating to the Java Virtual 
Machine and the browser. Such screen switching real- 
izes unprecedented and innovative virtual effects. Using 

55 the command for branching enables to dynamically 
switch over between playback of the video data as a 
movie in the movie mode and controls in the enhanced 
mode. In the case where the controls in the enhanced 
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mode are implemented by using a Java Virtual Machine 
and a browser, the video data recorded on the recording 
medium is played on either a screen for playing normal 
movies or a screen relating to the Java virtual Machine 
and the browser. Such screen switching realizes un- 
precedented and innovative virtual effects. 
[0008] The above configuration allows the playback 
device to execute games and the like that harness dy- 
namic mode switching, which results in enhancing the 
added value of the actual video data. In terms of branch- 
ing from the movie mode to the enhanced mode, a 
branch destination is specified by indirect referencing 
via a table. By designing -descriptive contents of the ta- 
ble, it is possible to realize operations for changing 
branch destinations of when the record medium is load- 
ed on a playback device having a Java Virtual Machine 
and a browser from those of when it is loaded on a play- 
back device not having those applications. As a result 
of the change in branch destinations, it is possible to 
close a path for branching to a program in the enhanced 
mode when the record medium is loaded on a playback 
device having no Java Virtual Machine and browser, and 
operation assurance for any type of playback devices 
can be thus realized. 

[0009] Here, in the recording medium, the table may 
include a plurality of indexes corresponding one-to-one 
with the plurality of programs; the indexes may show 
that the plurality of corresponding programs respective- 
ly belong to either the movie mode or the enhanced 
mode; and the indirect referencing is to specify a pro- 
gram of the branch destination by using labels relating 
to the indexes. 

[0010] Branching from a program to another program 
is implemented by referring to the indexes. Since each 
of the indexes shows a mode in which the corresponding 
program should be executed, it is possible to easily have 
the playback device execute branching involving mode 
switching where branching to another program is per- 
formed after modes being switched. 
[0011] Here, in the recording medium, the indexes 
may include a reserved index; and the reserved index 
may correspond to a movie-mode program used alter- 
natively to an enhanced-mode program when branching 
to the enhanced-mode program is instructed in a play- 
back device operable to execute only the movie mode. 
[0012] When the recording medium is loaded on a 
playback device not having the enhanced mode, 
branching is performed by referring to the reserved in- 
dex. Herewith, leading to the program in the movie mode 
at program branching is made possible. Since a path for 
branching to the program in the enhanced mode is 
closed, unintended false operations can be prevented. 
[0013] In the recording medium, a movie-mode pro- 
gram and an enhanced-mode program may be execut- 
ed by two or more execution modules; the two or more 
execution modules may. be resident programs on a 
same layer in a control hierarchy; and the playback con- 
trol procedure may be described using a function sup- 



plied from the control hierarchy layer. 
[0014] Here, in the recording medium, the supplied 
function may be one of (1) a function for having a play- 
back device execute a playback control based on a pre- 
5 defined playback path, (2) a function for setting a pre- 
determined value to a register in the playback device, 
and (3) a function for acquiring the value set to the reg- 
ister. 

[001 5] According to the above configuration, controls 

10 of taking over the register value in the movie mode and 
executing a different procedure according to the setting 
value can be realized in the enhanced mode. For exam- 
ple, in the case when a program in the enhanced mode 
is a procedure for moving a character on screen, taking 

is the setting value of the register over to the enhanced 
mode from the movie mode allows the playback device 
to execute a control procedure in which user settings for 
the video data is closely linked with the motion of the 
CG character. As a result of adopting such a control pro- 

20 cedure, it is possible to expand the range of expression 
for producing movie works, and to effectively enhance 
the added value of the video data with a fractional in- 
vestment of describing playback controls. Thus, the 
control procedure will become a powerful weapon for 

25 moviemakers and suppliers. 

[001 6] In the case of seeking a remarkable enhance- 
ment of the added value through producing games, in 
the recording medium, the enhanced mode may be a 
mode for having a virtual machine execute a program; 

30 and an enhanced-mode program may be described in 
a virtual machine-oriented programming language. 
[0017] An environment for developing the Java lan- 
guage (registered trademark) is established by realizing 
branching that involves mode switching, and it is thereby 

35 possible to have a number of software houses set their 
entry into the production businesses. As a result, many 
innovative styles of movie works will be created in which 
video data is played in association with switching over 
to the Java mode. Accordingly, this results in energizing 

to the market for movie works. 

[0018] In the case of seeking integration with a DVD 
playback environment, in the recording medium of 
Claim 13, a movie-mode program may include a button 
command; the button command may be a command for 

45 branching to the enhanced-mode program, and may be 
recorded on the recording medium as a multiplexed 
stream after being multiplexed with the video data and 
subtitle data; and each piece of the subtitle data may be 
image data of a button, and the button command may 

50 be executed when a confirmation operation is conduct- 
ed with respect to the image data of the button. 
[001 9] The button commands comply with commands 
comprehensible to DVD playback devices, and describ- 
ing control procedures using the button commands al- 

55 lows the compatibility of control procedures with DVDs. 
As a result of ensuring the compatibility, it is possible to 
standardize control structures in the case of releasing a 
single movie work in both DVDs and BD-ROMs, and to 
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reduce the need of authoring in the case of releasing 
movie works in BD-ROMs. 

[0020] Furthermore, a mode transition of branching 
from the DVD-like movie mode to the enhanced mode 
using a Java Virtual Machine and a browser is made 
possible, which allows playback controls involving both 
DVD functions and Java Virtual Machine/browser func- 
tions. 

[0021] In a situation where a browser is employed, a 
movie work could possibly be played with a website ma- 
ligning the movie work. If such playback is allowed, there 
is a risk of bringing discredit to the movie work. It is in- 
tolerably painful for moviemakers and suppliers that 
movie works on which they have worked are degraded, 
and this could be a cause to create frictions of movie- 
makers and suppliers with appliance manufacturers. 
[0022] In order to avoid such frictions, it is desirable 
to describe the programs in the enhanced mode in a 
markup language. 

[0023] Since the control procedures are described in 
a markup language, it is possible to enhance the added 
value of the video data by control procedures involving 
information retrieved from websites. Because informa- 
tion from which websites is taken up is decided by the 
creator side, it is possible to avoid movie works to be 
exposed to aspersion and defamation from general pub- 
lic via Internet. 

[0024] Technical significance of implementing mode 
transitions by indirect references via the table is not con- 
fined to the operation assurance as mentioned above. 
In the case when a certain condition is met on the play- 
back device side, it is possible to close a path for branch- 
ing from the movie mode to the enhanced mode, and 
therefore it is significant when playback devices are in 
the following situations: 

(1) when an encryption key for protecting a copy- 
right of a movie work is exposed in a playback de- 
vice, and the a playback device is made invalid by 
a key management center; 

(2) when there is a possibility that copies of a movie 
work will be circulated on networks as a result that 
a user made unauthorized copies of the movie work 
recorded on a recording medium by using ripper 
software; 

(3) when additional charge is not paid although it is 
required for execution of the enhanced modes; 

(4) when it is desired to cut a playback device off 
from a network due to an occurrence of a failure in 
a system of the playback device; 

(5) when there are version conflicts in Java Virtual 
Machines and browsers; 

(6) when there is a possibility of leakage of personal 
information or infection with virus software, and it is 
desired to cut a playback device off from a network; 
and 

(7) when it is desired to cut a playback device off 
from a network in order to protect movie works on 



a recording medium from an unauthorized device 
attempting to read recorded contents on the record- 
ing medium via a network. 

5 [0025] it is possible to cut off a mode transition when 
one of such situations (1 ) to (7) exists in playback de- 
vices. 

[0026] Even if playback devices are placed in an en- 
vironment where a constant network connection is avail- 

10 able, programs in the movie mode can be described so 
as to restrain transitions to a Java Virtual Machine and 
a browser in the cases, for example, when operations 
of playback devices and copyright protection of video 
data are not ensured and when a user has fallen into 

'5 debt default. Therefore, it is possible to cast aside cop- 
yright holders' fear when they distribute their movie 
works targeted for playback devices hooked up to home 
appliance networks. 

[0027] In addition, branch commands by indirect ref- 
20 erence as described above offer a significant advantage 
to distributors of movie works in that replacements at a 
later date can be realized with little effort. When certain 
pieces of the video data recorded on the recording me- 
dium have moral and ethical issues, the present inven- 
ts tion enables a user to watch replacement videos, in- 
stead of the problematic videos, by having the playback 
device download a table and the replacement videos 
and causing the playback device to make indirect refer- 
encing via the new table during playback. There is no 
30 need to rewrite all the programs recorded on the record- 
ing medium when partial replacement is desired, which 
allows to avoid the risk of recalling the recording medium 
even when such problems are raised. 
[0028] In addition to the case where replacing videos 
35 is wanted, when it is desired not to have playback de- 
vices play certain pieces, from among multiple pieces 
of the video data recorded on the recording medium, or 
when it is desired to shuffle the order of the video data 
pieces recorded on the recording medium, all required 
40 is to download a table. Thus, there is no need to rewrite 
programs on the record medium, and therefore burden 
of the distributors can be alleviated when problems are 
found. 

[0029] The broadest concept of the recording medium 
45 according to the present invention may be as follows. 
[0030] A recording medium having video data and a 
program recorded thereon, wherein the program shows 
a playback control procedure of the video data, 

an execution of the playback control procedure is 
so triggered with an event that occurs in a playback device 
during video data playback, and 

the event is one of (i) an event showing that a cur- 
rent playback position has reached a predetermined 
time point on a playback time axis of the video data, and 
55 (ii) an event showing that a current playback po- 

sition has proceeded by a predetermined time interval 
on the playback axis. 

[0031] The broadest concept of the playback device 
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according to the present invention may be as follows. A 
playback device relating to a recording medium having 
video data and a program recorded thereon, comprising 
a playback control engine operable to cause an occur- 
rence of an event synchronizing with video data play- 5 
back and playback progress, and 

an execution module operable to execute an event 
handler when the playback control engine causes the 
event occurrence, 

the event is one of (i) an event showing that a cur- io 
rent playback position has reached a predetermined 
time point on a playback time axis of the video data, and 
, (ii) an event showing that a current playback po- 
sition has proceeded by a predetermined time interval 
on the playback axis. 15 
[0032] Since the program that operates in synchroni- 
zation with the video data playback can be created as 
an event handler, the development by programmers can 
be facilitated. 

20 

Brief Description Of The Drawings 
[0033] 

FIG. 1 shows a usage application of a recording me- 25 

dium according to the present invention; 

FIG. 2 shows a structure of a BD-ROM; 

FIG. 3 shows an application layer format of the 

BD-ROM by using a directory structure; 

FIG. 4 is a classification diagram in which files are 30 

classified from a functionality viewpoint; 

FIG. 5 shows a layer model of software that a 

BD-ROM targets; 

FIG. 6 schematically shows how an AV stream is 
configured; 35 
FIG. 7 schematically shows how the AV stream is 
recorded on the BD-ROM; 
FIG. 8 shows an internal structure of Stream Man- 
agement Information; 

FIG. 9 shows an internal structure of PL information; 40 
FIG. 10 schematically shows indirect referencing 
with the use of PL information; 
FIG. 11 shows an example of when a different PL 
to the PL shown in FIG. 10 is defined; 
FIG. 1 2 shows playback modes on Layer 4 (dynam- 45 
ic scenarios) of the layer model; 
FIG. 13 shows movie works created through dy- 
namic playback controls of three modes; 
FIG. 14 shows a structure of Navigation Button in- 
formation; 50 
FIG. 15 shows an example of when button controls 
are implemented using the Navigation Button infor- 
mation multiplexed on the AV stream; 
FIG. 1 6 shows an example of a MOVIE object in the 
case where the Navigation Button information in the 55 
AV stream is set as shown in FIG. 15; 
FIG. 17 shows an exemplified description of a Java 
object in the case where branching is performed 



with a command of the MOVIE object of FIG. 16; 
FIG. 1 8 shows a relationship between a MOVIE ob- 
ject and a Java object; 

FIG. 1 9 schematically shows a Title composed of a 
character introduction in the MOVIE mode and a 
game in the Java mode; 

FIG. 20 schematically shows PL playback per- 
formed with the Java object; 
FIG. 21 shows a scene extraction performed using 
a different PL from one used in the MOVIE mode; 
FIG. 22 shows an exemplified description of a Web- 
Page object; 

FIG. 23A shows an internal structure of INFO. 
BD-ROM; 

FIG. 23B shows Indexes in an Index Table; 

FIG. 24A shows a BD-ROM on which a plurality of 

dynamic scenarios (001. MOVIE, 002.MOVIE, 

003.MOVIE 001 .CLASS, 002. CLASS, 

003.CLASS, ...) is recorded; 
FIG. 24B shows an exemplified description of the 
Index Table of when a plurality of dynamic scenarios 
as shown in FIG. 24A is described in a BD-ROM; 
FIG. 25A shows indirect referencing in a full system 
of when the Index Table is described as in FIG. 24B; 
FIG. 25B shows indirect referencing in a core sys- 
tem; 

FIG. 26 schematically shows how branching from 
the MOVIE object shown in FIG. 1 8 to the Java ob- 
ject is performed; 

FIG. 27 shows what kind of branching is performed 
when a BD-ROM having the scenarios shown in 
FIG. 1 8 recorded thereon is loaded in a core system 
playback device; 

FIG. 28 shows an internal structure of a playback 
device according to the present invention; 
FIG. 29 is a flowchart showing processing proce- 
dures performed by a module manager 20; 
FIG. 30 is another flowchart showing processing 
procedures performed by the module manager 20; 
FIG. 31 is a flowchart showing an execution proce- 
dure of a PL Play function performed by a playback 
control engine 12; 

FIG. 32 shows a file structure of a BD-ROM accord- 
ing to a second embodiment; 
FIG. 33 shows a data structure common to a 
PLMark and a ClipMark; 

FIGs. 34A and 34B show exemplified descriptions 
of PLMarks for defining TimeEvents appearing dur- 
ing playback of PL#1 ; 

FIG. 35 shows an exemplified description of a 
PLMark for defining a UserEvent during playback 
ofPL#1; 

FIG. 36 shows examples of event handlers driven 
by TimeEvents; 

FIG. 37 shows an example of an event handler driv- 
en by a UserEvent; 

FIG. 38 shows conditional branching as a result of 
event handlers by combining pictures played in the 
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PLs and images rendered by the event handlers of 
FIGs. 36 and 37; 

FIG. 39 shows processing procedures of a playback 
control engine 12 according to the second embod- 
iment; 

FIG. 40 is a schematic diagram for illustrating the 
technical significance of Backward Events; 
FIG. 41 A is an example of screen display obtained 
at a time when PL playback in the Java mode is 
started; 

FIG. 41 B is an example of screen display of when 

the PL playback point has reached Time t1; 

FIG. 41 C is an example of screen display of when 

the PL playback point has reached Time t2; 

FIG. 42A shows an example of screen display of 

when the PL playback point has reached Time t1 

after a rewind; 

FIG. 42B shows an example of screen display of 
when the PL playback point has reached Time to 
after the rewind; 

FIG. 42C shows an example of screen display of 
when the PL playback point has reached Time t1 
again; 

FIG. 43 schematically shows Time Event occurrenc- 
es during fast-forwarding; 

FIG. 44A is an example of screen display obtained 
at a time when PL playback in the Java mode is 
started; 

FIG. 44B is an example of screen display of when 

the PL playback point has reached Time t1 ; 

FIG. 44C shows an example of screen display of 

when a fast-forward is performed at the PL playback 

point having reached Time t2; 

FIG. 45 schematically shows an occurrence of a 

Pause Event; 

FIG. 46 shows a menu hierarchy realized by a 
BD-ROM; 

FIG. 47 shows MOVIE objects for operating menus 
having such a hierarchy; 

FIG. 48 shows processing procedures performed 
by a module manager 20 according to a fourth em- 
bodiment; 

FIG. 49 shows member functions of classes belong- 
ing to the Java mode; 

FIG. 50 shows controls via member functions in the 
Java mode; 

FIG. 51 shows a menu hierarchy according to a 
sixth embodiment; 

FIG. 52 shows MOVIE objects and an Index Table 
according to the sixth embodiment; 
FIG. 53 shows an example of a schedule table; 
FIG. 54 shows a structure of PL information accord- 
ing to a seventh embodiment; 
FIG. 55 shows hierarchical sharing where each 
piece of PL information is exclusively used by the 
MOVIE mode or the Java mode while a digital 
stream is shared by the MOVIE and Java modes; 
FIG. 56 is a flowchart showing BD-ROM production 



processes according to an eighth embodiment; and 
FIG. 57 shows an example of a playback control for 
branching directly from Navigation Button informa- 
tion in the AV stream to a Java object. 

5 

Best Mode for Carrying Out the Invention 
/. First Embodiment 

io [0034] The following gives an account of a preferred 
embodiment of a recording medium according to the 
present invention. First, a usage application is described 
in relation to the implementation of the recording medi- 
um of the present invention. FIG. 1 shows a usage ap- 

'5 plication of the recording medium according to the 
present invention. A BD-ROM 100 in FIG. 1 is the re- 
cording medium of the present invention. The BD-ROM 
1 00 is used for supplying movie works to a home theater 
system composed of a playback device 200, a television 

20 300, and a remote controller 400. 

[0035] Next, a production application is described in 
relation to the implementation of the recording medium 
of the present invention. The recording medium of the 
present invention can be implemented as a result of im- 

25 provements in the application layer of BD-ROMs. FIG. 
2 shows a structure of a BD-ROM. 
[0036] Level 4 in the figure shows the BD-ROM, and 
Level 3 shows a track on the BD-ROM. The figure de- 
picts the track in a laterally drawn-out form, although the 

30 track is, in fact, formed in a spiral, winding from the in- 
side toward the outside of the BD-ROM. The track is 
composed of a lead-in area, a volume area, and a lead- 
out area. The volume area in the figure has a layer mod- 
el made up of a physical layer, a filesystem layer, and 

35 an application layer. The recording medium of the 
present invention is industrially manufactured by form- 
ing the data format shown in FIG. 2 on the application 
layer of a BD-ROM. 

[0037] FIG. 3 shows a format of the application layer 
40 (applications) of the BD-ROM by using a directory struc- 
ture. In the BD-ROM, as shown in the figure, JCLASS 
directory and BROWSER directory are located under 
BD-ROMAV directory, which is found under ROOT di- 
rectory. 

45 [0038] Under BD-ROMAV directory, there are files 
named INFO.BD-ROM, XXX.M2TS, XXX.CLPI, YYY 
PL, and ZZZ.MOVIE. Under JCLASS directory and 
BROWSER directory, individual files called ZZZ.CLASS 
and ZZZ.HTM are respectively located. 

so [0039] FIG. 4 is a classification diagram in which 
these files are classified from a functionality viewpoint. 
As shown in FIG. 4, a hierarchical structure composed 
of Layers 1 to 4 symbolizes the classification of the fig- 
ure. XXX.M2TS is classified in Layer 2 in the figure. 

ss XXX.CLPI and YYY. PL are classified in Layer 3 (static 
scenarios). ZZZ.MOVIE under BD-ROMAV directory, 
ZZZ.CLASS under JCLASS directory, and ZZZ.HTM un- 
der BROWSER directory are ail classified in Layer 4. 
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[0040] The classification (Layers 1 to 4) of FIG. 4 tar- 
gets a layer model as shown in FIG. 5. The following 
describes the layer model of control software that the 
BD-ROM targets, with reference to FIG. 5. 
[0041] Layer 1 of FIG. 5 is a physical layer in which 
supply controls relating to streams targeted for process- 
ing are implemented. As shown in Layer 1 , processing 
target streams have, as their supply sources, not only 
BD-ROMs but also various other kinds of recording and 
communication media including HDs (hard disks), mem- 
ory cards, and networks. Controls (disk accesses, card 
accesses, and network communications) directed to- 
wards these supply sources, such as HDs, memory 
cards, and networks, are implemented by Layer 1. 
[0042] Layer 2 is a decoding format layer. Layer 2 de- 
fines a decoding format used for decoding streams sup- 
plied by Layer 1 . The MPEG-2 decoding format is em- 
ployed in the present embodiment. 
[0043] Layer 3 (static scenarios) defines the static 
scenarios of streams. Static scenarios are playback 
path information and stream management information 
defined in advance by the disk creator, and playback 
controls based on these static scenarios are defined in 
Layer 3 (static scenarios). 

[0044] Layer 4 is for realizing the dynamic scenarios 
of streams. Dynamic scenarios are scenarios for dy- 
namically changing the progress of playback as a result 
of user operations and the device status, and playback 
controls based on these dynamic scenarios are defined 
in Layer4. In accordance with this layer model, files cor- 
responding to actual streams, static scenarios, and dy- 
namic scenarios are described below. 
[0045] First, a stream (XXX.M2TS) belonging to Layer 
2 is described. 

[0046] An AV stream (XXX.M2TS) is an MPEG-TS 
(Transport Stream) format digital stream, and is ob- 
tained by multiplexing a video stream, one or more audio 
streams, one or more subtitle streams, and the Naviga- 
tion Button information. The video stream means a vid- 
eo portion of a movie, the audio streams mean audio 
portions of the movie, the subtitle streams means sub- 
titles of the movie, and the Navigation Button informa- 
tion means procedures of dynamic playback controls 
that target menus. FIG. 6 schematically shows how the 
AV stream is configured. 

[0047] The AV stream (Level 4) is formed by (/) con- 
verting a video stream comprising a plurality of video 
frames (pictures p]1 , pj2, and pj3) and an audio stream 
comprising a plurality of audio frames (Level 1) respec- 
tively into PES packet sequences (Level 2), each of 
which is then converted to TS packets (Level 3), (//) like- 
wise converting the Navigation Button information (Lev- 
el 7) to a PES packet sequence (Level 6), which is then 
converted into TS packets (Level 5), (///) and then mul- 
tiplexing all the TS packets. The multiplexing involves 
arranging the TS packets storing video frames and the 
TS packets storing audio frames so that the audio 
frames are positioned close to the video frames that are 



to be read from the BD-ROM at the same time as the 
audio frames. Since the Navigation Button information 
relates to dynamic playback controls, the explanation is 
omitted here. In addition, subtitle steams have less to 
5 do with the present embodiment, and therefore have 
been left out from FIG. 6. 

[0048] The AV stream generated through the above 
process is portioned into a plurality of extents and re- 
corded in an area of the BD-ROM, as is the case with 
10 general computer files. FIG. 7 schematically shows how 
the AV stream is recorded on the BD-ROM. 
[0049] A length of each extent constituting the AV 
stream and an address Indicating where, in the 
BD-ROM, the extent is recorded are described in file 
'5 management information fk1 . 

[0050] It can be seen that, for each of three extents 
(Extent 1 , Extent 2, and Extent 3) obtained by portioning 
the AV stream, its address (adrl, adr2, and adr3, re- 
spectively) and the length (lengthl, Iength2, and 
20 Iength3) are described in the file management informa- 
tion fk1 . The AV stream is composed of one or more 
ACCESS UNITs, and can be cued in these ACCESS 
UNITs. An ACCESS UNIT is the smallest decoding unit 
that includes a single GOP (group of pictures) and audio 
25 frames to be read at the same time as the GOP. Gaps 
include: bidirectionally predictive (B) pictures, which are 
compressed using time-correlation characteristics with 
images to be played in the past direction and the future 
direction; predictive (P) pictures, which are compressed 
30 using time-correlation characteristics with images to be 
played in the past direction; and intra (I) pictures, which 
are compressed using spatial frequency characteristics 
(i.e. not time-correlation characteristics) in the images 
of individual frames. 
35 [0051] Note that the filename "XXX" in XXX.M2TS is 
an abstract representation of the 3-digit identification 
number appended to the AV stream in the BD-ROM. 
That is, the AV stream in FIG. 7 is uniquely identified 
with the "XXX". Thus completes the description of the 
40 stream (XXX.M2TS). It should be noted that the 3-digit 
number referred to here is merely exemplary, and any 
digit number can be used. 

1. 1 Static Scenarios 

45 

[0052] Static scenario files (XXX.CLPI and YYY.PL) 
are described below. 

[0053] Stream management information (XXX.CLPI) 
is management information relating to an individual AV 

so stream. FIG. 8 shows an internal structure of the stream 
management information. Since the AV stream is ob- 
tained by multiplexing video and audio streams and can 
be cued in ACCESS UNITs, management items of the 
stream management information include the attributes 

55 of the video and audio streams and where the cue po- 
sitions are in the AV stream. The lead -lines in the figure 
show up-close details of the structure of the stream 
management information. As shown by the line hn1 , the 
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stream management information (XXX.CLPI) is com- 
posed of "attribute information" relating to video and au- 
dio streams and "TMAP" which is a reference table for 
cuing ACCESS UNITs. 

[0054] Attribute information (Attribute), as shown by 
the dashed line hn2, are composed of attribute informa- 
tion relating to a video stream (Video Attribute Informa- 
tion), the number of pieces of the attribute information 
(Number), and attribute information relating to each of 
a plurality of audio streams multiplexed on the AV 
stream (Audio Attribute Information #1-#m). The man- 
agement information relating to the video stream, as 
shown by the dashed line hn3, indicates the compres- 
sion format used to compress the video stream (Cod- 
ing), and the resolution (Resolution), aspect ratio (As- 
pect), and frame rate (Framerate) of individual pieces of 
picture data structuring the video stream. 
[0055] On the other hand, the attribute information re- 
lating to the audio streams (Audio Attribute Information 
#1 -#m), as shown by the dashed line hn4, indicates the 
compression format used to compress the respective 
audio streams (Coding), and the channel number (Ch.) 
and corresponding language (Lang.) of respective audio 
streams. 

[0056] A time map (TMAP) is a reference table for re- 
ferring indirectly to the addresses of a plurality of cue 
positions using time information. As shown by the 
dashed line hn5, TMAP is composed of plural pieces of 
entry information (ACCESS UNIT#1 entry, ACCESS 
UNIT#2 entry, ACCESS UNIT#3 entry,...) and the 
number of pieces of the entry information (Number). As 
shown by the dashed line hn6, each piece of the entry 
information is composed of a playback duration (Dura- 
tion) and a data size (Size) of a corresponding ACCESS 
UNIT, with the playback duration and the data size being 
associated with each other. Since a variable-length cod- 
ing compression format is employed, it is possible to cue 
from an arbitrary playback time to a piece of picture data 
in an ACCESS UNIT corresponding to the playback time 
by referring to the entry of the ACCESS UNIT, even 
when sizes and playback durations of ACCESS UNITs 
that include GOPs are not uniform. Note that the filena- 
me "XXX" of XXX.CLPI uses the same name as that of 
the AV stream to which the stream management infor- 
mation corresponds. In other words, the filename of the 
AV stream in FIG. 8, being "XXX", corresponds to the 
AV stream (XXX.M2TS). Thus concludes the description 
of the stream management information. Next is de- 
scribed playlist information (hereinafter referred to as PL 
information). 

[0057] YYY.PL (PL information) is a table structuring 
a playlist, which is playback path information, and is 
composed of CellList. FIG. 9 shows an internal structure 
of PL information. 

[0058] CellList comprises plural pieces of Cell infor- 
mation (Cell Information #1, #2, #3,..., #n) and the 
number of pieces of the Cell information (Number). Cell 
information is pointer information that defines one or 



more logical playback sections structuring a playlist. 
The structure of a piece of Cell information is shown in 
close detail as indicated with the line hs1 . As shown by 
the line, a piece of Cell information is structured from a 

5 "Stream Name" indicating the name of the AV stream to 
which the In-point and Out-point of a playback section 
belong, and an "In-point Information" which is informa- 
tion showing the start of a playback section, and an 
"Out-point Information", which is information showing 

10 the end of a playback section. 

[0059] Cell information is characterized by the nota- 
tion. That is, playback sections are defined by an indirect 
referencing format that uses a time map as a reference 
table. FIG. 10 schematically shows indirect referencing 

'5 with the use of PL information. The AV stream in the 
figure is structured from a plurality of ACCESS UNITs. 
The TMAP in the stream management information spec- 
ifies the sector address of the ACCESS UNITs, as 
shown by the arrows ay 1 , ay2, ay3, and ay4. Arrows ]y1 , 

20 jy2, jy3, and jy4 4 in the figure schematically show the 
referencing of ACCESS UNITs using the Cell informa- 
tion. In other words, it can be seen that referencing by 
the Cell information (arrows jy1, jy2, jy3, and jy4) in- 
volves indirect referencing in which the addresses of 

25 ACCESS UNITs included in the AV stream are specified 
via the TMAP. 

[0060] Playback sections on the BD-ROM that are 
formed from groupings of Cell information, stream man- 
agement information, and the AV stream are called 

30 "CELLs". Logical playback units on the BD-ROM that 
are formed from groupings of PL information, stream 
management information, and the AV stream are called 
"PlayLists" (abbreviated as "PL"). Movie works recorded 
on the BD-ROM are structured in these logical playback 

35 units (PLs). Therefore, it is possible to easily create, as 
distinct from the actual movie, movie works made of only 
scenes in which a certain character appears by defining 
a PL specifying these scenes. FIG. 11 shows an exam- 
ple of when a different PL (PL information #2) to the PL 

40 (PL information #1) shown in FIG. 10 is defined. 

[0061] The greatest merit of static scenarios is being 
able to increase the range of a moviemaker's expres- 
sion, since the variations of movie works increase sim- 
ply by defining various pieces of PL information. 

45 [0062] There are, in addition to PLs and CELLs, play- 
back units in the BD-ROM called Chapters. Chapters 
are structured from one, two, or more CELLs. 
[0063] Also, the filename "YYY" of the PL information 
is an abstract representation of the 3-digit identification 

so number appended to PL information in the BD-ROM. 
That is, the PL information in FIG. 11 is uniquely identi- 
fied using the identification number, "YYY". Expressing 
the identification number of the PL information as "YYY" 
shows that this identification number is a different num- 

55 bering system to the identification number "XXX" of the 
AV stream and AV stream management information. It 
should be noted that the 3-digit number referred to here 
is merely exemplary, and any digit number can be used. 
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[0064] Thus concludes the description of static sce- 
narios. Next are described dynamic scenarios. 

1.2 Dynamic Scenarios 

5 

[0065] Dynamic scenarios are programs showing 
playback controls relating to the AV stream. Playback 
controls by dynamic scenarios change in response to 
user operations on a device, and are similar to programs 
in character. Here, dynamic playback controls have two to 
modes. One of the two modes is a mode for playing vid- 
eo data recorded on the BD-ROM (normal mode) in a 
playback environment specific to AV devices, and the 
other mode is for enhancing the added value of video 
data recorded on the BD-ROM (enhanced mode). FIG. 15 
12 shows playback modes on Layer4 of the layer model. 
One normal mode and two enhanced modes are shown 
on Layer 4 in the figure. The normal mode, called a 
MOVIE mode, is a playback mode for a DVD-like envi- 
ronment (i.e. a mode similar to a playback mode used 20 
for DVDs). Of the two enhanced modes, the first, called 
a Java mode, is a playback mode used mainly with Java 
Virtual Machines. The second enhanced mode, called 
a Browser mode, is a playback mode used mainly with 
browsers. 25 
[0066] Since there are three modes on Layer 4 (i.e. 
the MOVIE mode, Java mode, and Browser mode), it is 
preferable to describe dynamic playback controls so as 
to be executed in either one of the modes. When control 
procedures are described in commands that closely re- 30 
semble DVD player-oriented commands, it is possible 
to have a playback device execute playback controls 
that closely resemble those in existing DVD playback 
devices. When control procedures are described using 
a page-description language, it is possible to describe 35 
control procedures for accessing network sites and 
downloading files, for example. FIGs. 13A-13C show 
movie works created through dynamic playback con- 
trols of three modes. 

[0067] FIG. 1 3 A shows one scene from a movie work 40 
created by defining dynamic playback controls in the 
MOVIE mode. Since the MOVIE mode allows to de- 
scribe playback controls in commands that closely re- 
semble those comprehensible to DVD playback devic- 
es, it is possible to define playback controls similar to *5 
those used for DVDs, that is, playback controls that al- 
low the progress of playback according to a selection 
made on a menu. 

[0068] FIG. 1 3B shows a movie work created by de- 
fining dynamic playback controls in the Java mode. The so 
Java mode allows a description of control procedures in 
the Java language comprehensible to Java Virtual Ma- 
chines. In the case where playback controls are for con- 
trolling motion of computer graphics (CG), it is possible 
to define a playback control, in the Java mode, for a CG 55 
image moving around (an owl in the figure) next to a 
window showing videos, for example. 
[0069] FIG. 13C shows a movie work created by de- 



fining dynamic playback controls in the Browser mode. 
The Browser mode allows a description of playback con- 
trols in the HTML language comprehensible to brows- 
ers. In the case where playback controls are for control- 
ling accesses to websites and window operations, it is 
possible to define a playback control in the Browser 
mode for displaying online data retrieved from a website 
(the bulletin board for Character A and banner advertis- 
ing in the figure) next to a window showing videos, for 
example. 

[0070] Thus concludes the general description of dy- 
namic scenarios. The following describes files that de- 
fine playback controls of individual modes, with respect 
to each mode. 

1.3 Dynamic Scenarios In MOVIE Mode 

[0071] The following description relates to dynamic 
scenarios in the MOVIE mode. Dynamic scenarios in the 
MOVIE mode include the Navigation Button information 
in transport streams and MOVIE objects. 
[0072] The Navigation Button information, which is 
one of streams multiplexed on the AV stream, controls 
the behavior of buttons on a menu, and executes play- 
back controls in response to a confirmed button. The 
menu behavior includes (i) changing a button status on 
the menu in response to a push down of an arrow key 
on the remote control, (ii) updating a register value in a 
playback device according to a button confirmation on 
the menu, and (Hi) realizing branching in response to a 
button confirmation on the menu. Controlling the behav- 
ior and having a playback device execute commands 
according to buttons are roles of the Navigation Button 
information. FIG. 14 shows a structure of the Navigation 
Button information. The Navigation Button information 
is composed of Button control information and Image 
Data. Image data comprises, as indicated by the dashed 
line hh1 , plural pieces of PNG data (PNGs) and a look 
up table (Common CLUT) to which all pieces of PNG 
data make reference. Individual pieces of the PNG data 
(PNG data #1 , PNG data #2, and PNG data #3) in Image 
Data are image data for rendering each button (Button 
#1 , Button #2, and Button #3) on the menu. 
[0073] The Button control information comprises, as 
indicated by the dashed line hh2, Page Affiliation infor- 
mation and Button Affiliated information. The Page Af- 
filiation information is, as indicated by the dashed line 
hh3, structured from "Button display begin Time", which 
indicates a beginning time for displaying buttons, "But- 
ton display end Time M t which indicates an ending time 
for the display, and "Initially selected Button", which in- 
dicates a button to be in selected state at the initial con- 
dition. 

[0074] The Button Affiliated information is, as indicat- 
ed by the dashed line hh4, structured from plural pieces 
of Button Affiliation #1, Button Affiliation #2, ... and so 
on. Each piece of the Button Affiliations is, as indicated 
by the dashed line hh5, composed of "Button image in- 
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formation" that indicates, from among plural pieces of 
the PNG data, which is an image for a corresponding 
button, "Button display location" that indicates a location 
of the button image, "Relationship with upper/lower/side 
buttons" that indicates which buttons are located on the 
left, right, above and below of the button, respectively, 
and "Button Command" to be executed when the button 
is confirmed. 

[0075] In the Button Affiliated information related to in- 
dividual buttons on a menu, which buttons are located 
on the left, right, above and below of each button is de- 
scribed. Therefore, it is possible to, in response to a 
push down of an arrow key on the remote control by a 
user, identify a button located along the direction indi- 
cated by the pushed arrow key by referring to the Rela- 
tionship with upper/lower/side buttons in Button Affiliat- 
ed information, and then change a state of the button. 
Thus, according to the push down of an arrow key, the 
state of a button in the direction indicated by the key is 
changed. Subsequently, when the confirmation opera- 
tion is performed by a user, it is possible to execute a 
dynamic playback control according to the pushed but- 
ton by implementing Button Command of the Button Af- 
filiated information corresponding to the button. 
[0076] Since the Navigation Button information is in- 
corporated in the AV stream, it is convenient in the de- 
scription of playback controls for having a playback de- 
vice execute specific processing according to a timing 
at which a particular frame of videos appears on a 
screen, that is, playback controls synchronized precise- 
ly with the video contents. In addition, since the Naviga- 
tion Button information is multiplexed on the actual AV 
stream, even when there are hundreds of sections 
needing to perform playback controls, there is no need 
to store all the Navigation Button information corre- 
sponding to the sections in memory. The Navigation 
Button information is read from the BD-ROM for every 
ACCESS UNIT along with video packets. Therefore, it 
is preferable to have pieces of the Navigation Button in- 
formation corresponding to a video section for the cur- 
rent playback reside in memory, and then to delete these 
pieces of the Navigation Button information from mem- 
ory when playback of this video section is over and store 
pieces of the Navigation Button information correspond- 
ing to the next video section in memory. Since the Nav- 
igation Button information is multiplexed on the AV 
stream, the installed memory can be kept to a minimum 
required amount even when, for instance, there are hun- 
dreds of pieces of the Navigation Button information. 
[0077] An exemplified description of commands relat- 
ed to the Navigation Button information is explained with 
referenceto FIG. 15. FIG. 15showsan exampleof when 
button controls are implemented using the Navigation 
Button information multiplexed on the AV stream. 
[0078] The AV stream in FIG. 1 5 is a movie, and mul- 
tiple buttons in the figure are displayed, being combined 
with one frame of the movie. Buttons A, B, and C in the 
figure each correspond to characters appearing in the 



movie works, and the state of each button is switched 
between selected and confirmed states through a se- 
lection operation for selecting one of Characters A, B, 
and C appearing in the movie. 
5 [0079] In FIG. 15, the Navigation Button information 
is placed, in the video stream, ahead of a period where 
an interactive operation is required. When a button on 
a menu is confirmed, the Navigation Button information 
multiplexed on the AV stream in the figure sets GPRM 
10 (0) to a value unique to the button. GPRM (0) is a register 
setting value managed on Layer 3 (static scenarios) in 
the layer model. Specifically speaking, GPRM(0) is set 
to "1 " when the button for Character A is confirmed, and 
GPRM(0) is set to "2" when the button for Character B 
15 js confirmed. When the button for Character C is con- 
firmed, GPRM(0) is set to "3". Rendering the Navigation 
Button information in this way allows for saving, in 
GPRM(0), information on which button was selected at 
the time of the menu rendered. Thus completes the de- 
scription of the Navigation Button information. 
[0080] A MOVIE object (XXX.MOVIE) is a dynamic 
scenario described in commands that resemble those 
comprehensible to DVD playback devices. The MOVIE 
object is composed of a playback command for instruct- 
ing PL playback, a command to be executed prior to the 
PL playback (PRE command), and a command to be 
executed after the PL playback (POST command). Pair- 
ings of one or more MOVIE objects with PLs whose play- 
back is instructed with individual MOVIE objects is 
called Titles. Titles are units that correspond to an entire 
movie work on the BD-ROM. "MOVIE object" is some- 
times shortened to "M-OBJ" below. 
[0081] FIG. 16 shows an example of the MOVIE ob- 
ject in the case where the Navigation Button information 
in the AV stream is set as shown in FIG. 15. The MOVIE 
object in the figure is composed of: a PRE command for 
setting GPRM{0) to "0"; a command for instructing a 
playback device to perform PL playback, (Play PI 
(PL#1)); and a POST command for instructing the play- 
back device to perform branching to another dynamic 
scenario, (IF(GPRM(0)=0) {Jump Title#m}else{ Jump Tl- 
tle#m+1}). As a result of the PRE command, GPRM(0) 
is initialized prior to PL playback. Branching to MOVIE 
object #m+1 is performed if GPRM(0) shows "0", which 
is a value at the initialization. On the other hand, if a 
button selection is performed when a menu is displayed 
and GPRM(0) is set to a value other than "0", then 
branching is performed to another Title (Title#m). 
[0082] If commands for changing the register setting 
value according to user operations are incorporated in 
the Navigation Button information, and conditional 
branching using the register setting value in a playback 
device is described as the POST commands, it is pos- 
sible to easily create a multi-story movie, namely a mov- 
ie work whose progress of playback can be changed ac- 
cording to user operations. 

[0083] Since there are two types of scenarios in the 
MOVIE mode (Navigation Button information and MOV- 
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IE objects), processing needing to synchronize precise- 
ly with the button behavior on a menu can be described 
in Navigation Button information, and integrative 
processing such as pre- and post-processing for PL 
playback can be described in MOVIE objects. Thus, the 5 
command description can be changed depending on 
whether processing to be synchronized with buttons or 
integrative processing, which increases the range of ex- 
pression for playback controls. Furthermore, the de- 
scription of playback controls does not require playback 10 
devices to have large capacity memory by writing new 
Navigation Button information over old one, even if the 
number of playback controls needing to synchronize 
with buttons increases. 

15 

1.4 Dynamic Scenarios in Java Mode 

[0084] The following explains dynamic scenarios 
used in the Java mode. 

[0085] 2ZZ.CLASS is a class file in which application 20 
programs (Java objects) specifying dynamic playback 
controls in the Java mode are defined. Since a Java Vir- 
tual Machine is a main execution body of scenarios in 
the Java mode, Java objects are described in the Java 
language. In late years, the Java language (registered 25 
trade name) that is a middleware-oriented description 
language developed by SUN Microsystems, Inc., has 
been increasingly in widespread use in consumer appli- 
ances, such as Japanese cellular phones and 
DVB-MHPs (Digital Video Broadcasting-Multimedia 30 
Home Platform) for European digital broadcasting. As 
with C++, the Java language is an object-oriented pro- 
gramming language. The difference from C++ is that, 
while C++ is implemented in operating systems, the 
Java language defines Java Virtual Machines and is im- 35 
plemented in main operating systems, such as Windows 
and Linux. Therefore, the use of the Java language al- 
lows descriptions of processing procedures independ- 
ent of operation systems. The reason the Java language 
has been adopted for cellular phones and STBs (set-top *o 
boxes) is that, even if the execution environments differ 
from maker to maker, the Java language is able to de- 
scribe execution environment-independent processing 
procedures. "Java object" is sometimes shortened to 
"J-OBJ" below. 45 
[0086] FIG. 1 7 shows an exemplified description of a 
Java object in the case where branching is performed 
by a command of the MOVIE object shown in FIG. 16. 
The Java object performs procedures of (i) rendering a 
CG, and (ii) playing a CELL in a PL, according to a value so 
in GPRM(0). Such procedures realize creating a com- 
bined image as shown in FIG. 13B, that is, a combined 
image where a CG of a character is set in motion next 
to video data structuring the PL being played. Note that 
the IF statement of the exemplified description changes 55 
a character to be rendered and a CELL to be played 
according to GPRM(0). 

[0087] The following explanation is given focusing at- 



tention on a CG to be rendered. In an example shown 
in FIG. 17, n A.drawCharacter();" means that the Object 
of Character A is rendered on the screen using one of 
the methods (i.e. the drawCharacter function in the fig- 
ure) of the Class "Character A". Likewise, "B.drawChar- 
acterQ;" and "C.drawCharacterQ;" mean respectively 
that the Objects of Characters B and C are rendered on 
the screen using one of the methods (i.e. the drawChar- 
acter function in the figure) of the Classes "Character B" 
and "Character C". 

[0088] Since "A.drawCharacterO;", "B.drawCharac- 
ter(); tt , and "C.drawCharacterO;" are executed exclu- 
sively depending on the value of GPRM(0) (IF state- 
ments in FIG. 17), the CG of Character A is rendered if 
GPRM(0) is "1", the CG of Character B is rendered if 
GPRM(0) is M 2", and the CG of Character C is rendered 
if GPRM(0) is "3". FIG. 1 8 shows a relationship between 
a MOVIE object and a Java object. The left half of the 
figure is identical to the exemplified description of the 
MOVIE object shown in FIG. 16. GPRM(0) in the figure 
is set by the Navigation Button information incorporated 
in the AV stream. GPRM(0) is a parameter managed on 
Layer 3 (static scenarios) in the layer model. Since 
GPRM(0) can be referred to in any mode of the MOVIE 
mode, Java mode, and Browser mode, processing of a 
Java object can be switched according to GPRM(0) that 
has been set in the MOVIE mode. The value in GPRM 
(0) can be changed by the Navigation Button information 
in the MOVIE mode, and a CG to be rendered can be 
switched in the Java mode. With cooperation between 
a MOVIE object and a Java object through GPRM(0), it 
is possible to create a new style of movie works where 
playback of video data and processing performed by 
Java Virtual Machines are integrated. 
[0089] If the Java object processing according to a 
value of GPRM(0) is, for example, a game starring one 
of Characters A, B, and C, the procedures of: (1) intro- 
ducing characters with videos in the MOVIE mode; (2) 
accepting a character selection from a user; and (3) ex- 
ecuting, in the Java mode, the game starring a character 
selected by a user (such procedures can be commonly 
found in today's game software) can be readily de- 
scribed using video data of a movie. FIG. 19 schemati- 
cally shows a Title composed of a character introduction 
in the MOVIE mode and a game in the Java mode. As 
a result of the cooperation between the MOVIE mode 
and Java mode via GPRM(0), a series of procedures 
from the character introduction to the execution of the 
game starring a character can be easily described using 
a movie in the MOVIE mode. 
[0090] On the other hand, in the light of a CELL to be 
played, CELL#1 of PL#1 is rendered when GPRM(0) is 
"1", CELL#1 1 of PL#2 is rendered when GPRM(0) is 
-2", and CELL#1 of PL#3 is rendered when GPRM(0) is 
"3". 

[0091] Here, for example, CELL#2 of PL#1 is a play- 
back unit specifying, in the AV stream, only a section In 
which Character A appears. By playing this CELL to- 
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gether with a CG of Character A, it is possible to display 
a combined image (FIG. 1 3B) where the CG of Charac- 
ter A is moving around next to Character A in videos 
being displayed. FIG. 20 schematically shows PL play- 
back performed by a Java object. The Java object in the 5 
figure includes a function call which instructs playback 
of CELL#2 of PL#1 . In response to the function call, one 
of the CELLs structuring a PL is played. If PL#1 in the 
figure has been instructed to perform playback in the 
MOVIE mode, here only a section of CELL #2 is extract- 10 
ed for use in the Java object. Such a function call of the 
Java object achieves a straightforward "scene extrac- 
tion- in which, of a movie work (PL#1) to be played in 
the MOVIE mode, only a specific scenes (CELL#2) are 
used for the Java-mode game. The example of FIG. 20 is 
illustrates a scene extraction assuming PL sharing 
where a PL used in the MOVI E mode is used in the Java 
mode. Alternatively, a scene extraction can be per- 
formed using a PL different from one used in the MOVI E 
mode. FIG. 21 shows a scene extraction performed by 20 
using a different PL from one used in the MOVIE mode. 
[0092] These extractions of FIGs. 20 and 21 allow to 
easily create flashback scenes used for the Java mode 
game in the context of scenes from a movie being re- 
called in the game. Such extractions lead to an expan- 25 
sion of the range of expressions involved with producing 
movie works, and thus enhance the commercial value 
of BD-ROMs. Note that the examples of FIGs. 20 and 

21 perform extractions with respect to each CELL, how- 
ever a section that is instructed by the Java object for 30 
playback can be specified by time. Likewise, extractions 
can be performed in the Browser mode. Since game 
software that is incorporated with movie works or that 
uses scenes from a movie can be programmed in the 
Java language, it is possible to have a number of soft- 35 
ware houses set their entry into BD-ROM producing 
businesses. 

1.5 Dynamic Scenarios in Browser Mode 

40 

[0093] A WebPage object (2ZZ.HTM) is a scenario 
described in a page-description language, such as 
HTML, XML, and BML. "WebPage object" is sometimes 
shortened to "WP-OBJ" below. Since WebPage objects 
can be described In HTML, the Browser mode realizes 45 
descriptions of control procedures with the inclusion of 
accesses to websites, FIG. 22 shows an example of de- 
scription of a WebPage object. This exemplified descrip- 
tion is based on FIG. 18. The WebPage object in FIG. 

22 differs in making access to different websites accord- so 
ing to the value in GPRM(0). In other words, access is 
made to a website pertaining to Character A when 
GPRM(0) is "1", access is made to a website pertaining 

to Character B when GPRM(0) is "2", and access is 
made to a website pertaining to Character C when ss 
GPRM(0) is "3°. GPRM(0) in FIG. 22 is set by the Nav- 
igation Button information incorporated in the AV 
stream. In addition, since GPRM(0) is in Layer 3 (static 



scenarios) in the layer model, and can be referred to in 
any mode of the MOVI E mode, Java mode, and Browser 
mode, processing of a WebPage object can be switched 
according to GPRM(O) that has been set in the MOVIE 
mode. In the case where online data from websites is 
news and BBSs (bulletin board systems), which are up- 
dated on a daily or weekly basis, and banner advertis- 
ings, having these online data on display ensures keep- 
ing the impression of the video data always fresh. Addi- 
tionally, because WebPage objects allow descriptions 
of access procedures to web servers, it is possible to 
obtain the latest versions of PLs and VOBs (DVD Video 
Objects) from web servers, and to have a playback de- 
vice perform playback controls with the inclusion of 
these PLs and VOBs. Cooperation between a MOVIE 
object and a WebPage object through GPRM(0) leads 
to creating a new type of movie works where video data 
playback and browser processing are integrated. 
[0094] Afilebody "ZZZ" in the filenames, ZZZ.MOVIE, 
ZZZ. CLASS, and 777. HTM, is an abstract representa- 
tion of a 3-digit identification number appended to the 
individual dynamic scenarios in the BD-ROM. That is, 
the scenarios in FIG. 23 are uniquely identified with the 
identification number "ZZZ". Expressing the identifica- 
tion number of the scenarios as "777" shows that this 
identification number is a different numbering system to 
the identification number "XXX" of the AV stream and 
the identification number "YYY" of the PL information. It 
should be noted that the 3-digit number referred to here 
is merely exemplary, and any digit number can be used. 

1.6 Technique for Describing Scenarios 

[0095] Here is explained a technique for describing 
control procedures of MOVIE, Java, and WebPage ob- 
jects. In a layer model that these scenarios target, a 
DVD virtual player implementing MOVIE objects, a Java 
Virtual Machine implementing Java objects, and a 
browser implementing WebPage objects are all in Layer 
3 (static scenarios). In Java objects and Webpage ob- 
jects, intrinsic processing to be performed in the Java 
and Browser modes, such as CG rendering and website 
accesses, can be preferably described in the Java lan- 
guage and HTML, respectively. Any other processing, i. 
e. playback controls of the BD-ROM, can be described 
using programming functions supplied from Layer 3 
(static scenarios). 

[0096] The following description relates to functions 
supplied from Layer 3 (static scenarios). 
[0097] (a) Playback Functions: starting playback of a 
PL specified by a first argument from a position specified 
by a second argument 

Format: PlayPL (first argument, second argu- 
ment) 

[0098] The first argument is able to specify a PL for 
playback using the PL number. The second argument 
is able to specify a playback start position using a CELL 
included in the PL, and an arbitrary time, Chapter, and 
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SPRM{3) 


: number showing angle setting 






made by user 




SPRM(4) 


: number of Title currently targeted 






for playback 


5 


SPRM(5) 


: number of Chapter currently tar- 






geted for playback 




SPRM(6) 


: number of PL currently targeted 






for playback 




SPRM(7) 


: number of CELL currently target- 


10 




ed for playback 




SPRM(8) 


: time information showing current 






playback point 




SPRM(9) 


: count value of navigation timer 




SPRM(10) 


: number of button currently in se- 


15 




lected state 




SPRM(11)-(12) 


: Reserved 




SPRM(13) 


: setting of parental level by user 




SPRM(14) 


: setting related to image playback 






of playback device 


20 


SPRM(15) 


: setting related to audio playback 






of playback device 




SPRM(16) 


: language code showing audio set- 






ting in playback device 




SPRM(17) 


: language code showing subtitle 


25 




setting in playback device 




SPRM(18) 


: language setting for rendering 






menu 




SPRM(19)-(31): 


Reserved 
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Mark in the PL. 

[0099] A PlayPL function specifying a playback start 
position using a CELL is called a "PlayPLatCELLO"; 

a PlayPL function specifying a playback start po- 
sition using a Chapter is called a "PlayPLatChapter() M ; 

a PlayPL function specifying a playback start po- 
sition using a Mark is called a w PlayPLatMark()"; and 

a PlayPL function specifying a playback start po- 
sition using time information is called a "PlayPLatSpec- 
ified 7ime() M . 

[0100] (b) Functions for status acquisition and status 
setting of a playback device 

[0101] The status of a playback device is shown in 32 
individual Player Status Registers (the setting values of 
these registers are called System Parameters (SPRM)), 
and 32 individual General Purpose Registers (the set- 
ting values of these registers are called General Param- 
eters (GPRM)). 

[0102] MOVIE objects, Java objects, and WebPage 
objects are able, for example, to set values in and ac- 
quire values from these registers by using the following 
functions (i) to (iv). 

(i) "Get value of Player Status Register" Function 

Format: Get value of Player Status Register 
(argument) 

This function acquires setting values of Player 
Status Registers specified by arguments. 

(ii) "Set value of Player Status Register" Function 

Format: Set value of Player Status Register 
(first argument, second argument) 

This function causes values specified by the 
second argument to be set in Player Status Regis- 
ters specified by the first argument. 

(iii) "Get value of General Purpose Register" Func- 
tion 

Format: Get value of General Purpose Regis- 
ter (argument) 

This function acquires setting values of General 
Purpose Registers specified by the argument. 

(iv) "Set value of General Purpose Register" Func- 
tion 

Format: Set value of General Purpose Regis- 
ter (first argument, second argument) 

[0103] This function causes values specified by the 
second argument to be set in General Purpose Regis- 
ters specified by the first argument. 
[0104] The setting values (SPRM) of the Player Sta- 
tus Registers have the following meanings. The notation 
H SPRM(x)" below refers to the setting value of the x th 
Player Status Register. 

SPRM(0) : Reserved 

SPRM(1) : stream number of audio stream 

targeted for decoding 
SPRM(2) : stream number of subtitle stream 

targeted for decoding 



[01 05] SPRM (1 ) and SPRM(2) are set by a PRE com- 
mand prior to PL playback, and updated by a Button 
Command in Navigation Button information during play- 

35 back of the AV stream . The following application is made 
possible by referring to SPRM(1) and SPRM(2) . Here, 
for example, PL playback is being performed in the 
MOVIE mode with the audio and the subtitle set to Eng- 
lish and Japanese, respectively. If branching from the 

40 MOVIE mode to the Java mode is performed during the 
playback, a Java object is able to set the audio to English 
and set the subtitle to Japanese by referring to SPRM 
(1 ) and SPRM(2), and then able to execute software of 
the Java object. If the software of the Java object is a 

45 learning material for listening English, the synergy be- 
tween watching a movie and learning through the listen- 
ing material will improve the efficiency of language 
learning. 



[01 06] SPRM(3) is set by a PRE command prior to PL 
playback, and updated by a Button Command in the 
Navigation Button information during playback of the AV 
55 stream. In the case where multiangle sections are in- 
cluded in the AV stream, it can be found that video data 
in which angle is a target for decoding by referring to 
SPRM (3), 



so [SPRM(3)j 
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[0107] The following application is possible by refer- 
ring to SPRM(3). Here, for example, a movie work is a 
video showing scenery from a train, and contains multi- 
angle sections. The multiangle sections include plural 
pieces of video data taken from multiple angles, such 5 
as angles from passenger seats on the right and left 
sides of the train and an angle from the driver's seat. In 
this case, SPRM(3) shows the angle of playback. There- 
fore, at the time of branching from the MOVIE mode to 
the Java mode, a Java object is able to realize a driving to 
game involving playback of images taken from an angle 
set by a user by referring to SPRM(3). 

[SPRM(4)-SPRM(7)] 

15 

[0108] SPRM(4) is updated when a Title is selected 
by a user via a menu operation. SPRMs(5)-(7) are up- 
dated whenever the current playback point proceeds. 
That is, SPRM(7) is updated if the current playback point 
moves from one CELL to another CELL, SPRM(6) is up- 20 
dated if one PL is switched to another PL, and SPRM 
(5) is updated if one Chapter is switched to another 
Chapter. 

[0109] In this way, which Title, which PL, which CELL 
or which Chapter in the PL, or which CELL that a play- 25 
back device is currently playing can be found by refer- 
ring to SPRMs(4)-(7). It should be noted that SPRMs(4) 
-(7) are not directly updated by PRE commands, POST 
commands, and Button commands, but they are updat- 
ed by commands for PL playback. Although thus per- 30 
formed indirectly, the updates are implemented with dy- 
namic scenarios, and therefore it can be said that 
SPRMs(4)-(7) are updated with dynamic scenarios. 

[SPRM(10)J 35 

[0110] SPRM(10) is updated whenever each piece of 
picture data belonging to the AV stream is displayed. 
That is, if a playback device displays new piece of pic- 
ture data, SPRM(10) is updated to a value indicating a <o 
display start time (Presentation Time) of the new piece 
of picture data. In the case where a Button Command 
in Navigation Button information has been described so 
that a transition from the MOVIE mode to the Java mode 
is performed during PL playback, a Java object in the *s 
Java mode is able to find a point to which a user has 
finished watching the movie work on the BD-ROM 
where the Button Command is stored. Additionally, in 
the Java mode, game software can be described so that 
appearing characters will be changed depending on the so 
watching point in the movie work, which makes games 
in the Java mode more exciting. It should be noted that 
SPRM(10) is not directly updated by PRE commands, 
POST commands, and Button commands, but it is up- 
dated by commands for PL playback. Although thus per- 55 
formed indirectly, the updates are implemented with dy- 
namic scenarios, and therefore it can be said that SPRM 
(10) is updated with dynamic scenarios. 



[0111] Java objects and Web Page objects are able to 
find the status of a playback device in detail by referring 
to the Player Status Registers using the "Get value of 
Player Status Register" function and the "Get value of 
General Purpose Status Register" function. 
[01 1 2] (c) There also exist branches from one dynam- 
ic scenario to another dynamic scenario, although these 
are not programming functions supplied from Layer 3 
(static scenarios). Functions for executing branches 
from one dynamic scenario to another dynamic scenario 
include the following JMP and CALL functions. 
[0113] JMP function 

Format: JMP argument 
[0114] CALL function 

Format: CALL argument 
[01 1 5] The JMP function is a branch for discarding the 
current dynamic scenario during operation, and execut- 
ing a branch -destination dynamic scenario specified by 
the argument. JMP commands include direct reference 
commands that specify branch-destination dynamic 
scenarios directly, and indirect reference commands 
that specify branch-destination dynamic scenarios indi- 
rectly. 

[0116] The Call function is a branch for causing a 
branch -destination dynamic scenario specified by the 
argument to operate after suspending the operation of 
the current dynamic scenario, and then resuming the 
operation of the suspended scenario once the branch- 
destination dynamic scenario has ended. A Resume 
command is placed at the end of the dynamic scenario 
which is a branch destination of the Call command. The 
Resume command, which is the so-called Return com- 
mand of a subroutine, is for reactivating the dynamic 
scenario that have been in a suspended state due to the 
execution of the Call function. Call commands, as with 
JMP commands, include direct reference commands 
that specify branch-destination dynamic scenarios di- 
rectly, and indirect reference commands that specify 
branch-destination dynamic scenarios indirectly. 
[0117] Thus concludes the description of functions 
and variables supplied by Layer 3 (static scenario). 

/ . 7 Information for Integrated Management 

[01 1 8] The following gives an account of information 
for integrating and managing dynamic scenarios in the 
MOVIE mode, Java mode, and Browser mode. INFO. 
BD-ROM shown in FIG. 3 is such information for inte- 
grated management. 

[0119] FIG. 23A shows an internal structure of INFO. 
BD-ROM. As shown in the figure, INFO.BD-ROM in- 
cludes an Index Table. The Index Table is an indirect 
reference table that is referenced when branching from 
one dynamic scenario to another dynamic scenario is 
performed, and comprises Indexes corresponding one- 
toone with a plurality of labels. In each Index, a filename 
of a dynamic scenario corresponding to the label of the 
Index is described. As shown in FIG. 23B, each filename 
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comprises a filebody and an extension. The labels in- 
clude TITLE#1 -#m, TITLE #m+1 -#n, and TITLE#0. The 
Index Table is referred to from dynamic scenarios of any 
of the three modes. Branching from a MOVIE object to 
a Java object, or from a MOVIE object to a WebPage s 
object is only possible when via the Index Table. To re- 
phrase, it is not possible to branch from a MOVIE object 
to a Java or WebPage object that does not have an In- 
dex in the Index Table. 

[0120] TITLE#1-#m INDEXES are Indexes for the 1 s * w 
to ^ Titles entered in the BD-ROM. In these Indexes 
are described the filenames of MOVIE objects that are 
to be branch destinations when the 1 st to m^ Title num- 
bers are selected. FIG. 23B shows the content of the 
TITLE#1-#m INDEXES. As shown in the figure, the 15 
filenames of MOVIE objects are described in the Tl- 
TLE#1-#m INDEXES. Each filename comprises a file- 
body (ZZZ) and an extension (.MOVIE). 
[0121] The TITLE#m+1-#n INDEXES are Indexes for 
the m+1 th to n 01 Titles entered in the BD-ROM. In these 20 
Indexes are described the filenames of WebPage ob- 
jects/Java objects that are to be branch destinations 
when the m+1 th to n th Titles numbers are selected. FIG. 
23C shows an internal structure of the TITLE#m+1 -#n 
INDEXES. As shown in the figure, in each of the Tl- 25 
TLE#m+1-#n INDEXES is stored either the filebody 
(ZZZ) and extension (.CLASS) of a Java object or the 
filebody (ZZZ) and extension (.HTM) of a WebPage ob- 
ject. 

[0122] TITLE#0 INDEX is an Index for storing the 30 
filename of a MOVIE mode scenario that is executed, 
instead of an enhanced mode scenario, in the case 
when the BD-ROM is loaded in a playback device inop- 
erable to execute the enhanced mode, and branching 
to the enhanced mode is instructed by the playback de- 35 
vice. 

[0123] Here, inoperability of the enhanced mode ex- 
ecution arises when (1) a Java Virtual Machine to im- 
plement the Java mode or a browser to implement the 
Browser mode is not installed, (2) they have been unin- 40 
stalled, or (3) although they have been installed, the 
playback device is off from a network and used in a 
stand-alone configuration. A playback device in which 
the enhanced mode execution is not possible for any of 
the three reasons above is called a core system. On the 45 
other hand, a playback device in which program execu- 
tion using a Java virtual machine and a browser is pos- 
sible is called a full system. Indirect referencing of a 
BD-ROM by a core system and a full system is de- 
scribed below with reference to FIGs. 24A-24B. Here, so 
the description of indirect referencing assumes a 
BD-ROM on which a plurality of dynamic scenarios is 

recorded (001. MOVIE, 002.MOVIE, 003.MOVIE 

001 .CLASS, 002.CLASS, 003.CLASS, ...), as shown in 
FIG. 24A. FIG. 24B shows an exemplified description of 55 
an Index Table when the plurality of dynamic scenarios 
shown in FIG. 24A is described in the BD-ROM. In the 
exemplified description shown In FIG. 24B, the filena- 



mes of the MOVIE mode scenarios (001. MOVIE, 
002.MOVIE, 003.MOVIE, ...) are described in Ti- 
tle#1 Index to Title#mlndex. On the other hand, the 
filenames of enhanced mode scenarios (001 .CLASS, 

002. CLASS, 003.CLASS, ...) are described in Ti- 
tle#m+1 Index to Tltle#nlndex. FIG. 25A shows indirect 
referencing in a full system when the Index Table is de- 
scribed as in FIG. 24B. Because of the Index Table being 
described as such, filenames "001 .MOVIE, 002.MOVIE, 

003. MOVIE, ..." are retrieved from Title#1 Index to Tl- 
tle#mlndex when executing branch commands specify- 
ing labels Title#1 to Title#m as branch destinations, and 
filenames "001 .CLASS, 002.CLASS, 003. C LASS, ..." 
are retrieved from Title#m+1 Index to Title#nlndex when 
executing branch commands specifying labels Ti- 
tle#m+1 toTitle#n as branch destinations. Dynamic sce- 
narios specified by these filenames are then read to 
memory and executed. Thus concludes the description 
of indirect referencing by a full system. 

[0124] FIG. 25B shows indirect referencing in the core 
system. Filenames "001 .MOVIE, 002. MOVIE, 
003.MOVIE, ..." are retrieved from Title#1 Index to Tl- 
tle#mlndex when executing branch commands specify- 
ing labels Title#1 to Title#m as branch destinations. 
However, when executing branch commands specifying 
labels Title#m+1 to Title#n as branch destinations, 
filename "000.MOVIE" is retrieved from Title#0lndex in 
place of Title#m-»-1 Index to Title#nlndex. The playback 
device then executes the dynamic scenario specified by 
the filename. Thus concludes the description of indirect 
referencing by both a full system and a core system. 
[0125] FIG. 26 schematically shows how branching 
from a MOVIE object shown in FIG. 18 to a Java object 
is performed. The arrows jn1 and jn2 in the figure sym- 
bolically indicate the branching from a MOVIE object to 
a Java object. "Jmp Title#m+1 M in the figure is a branch 
command for branching to a Java object, and specified 
the Java object as a branch destination using an indirect 
referencing format via the Index of label Title#m+1 . The 
filename of the Java object is described in the Index of 
label Title#m+1 , and the playback device is able to find 
which file to read as the Java object by referring to this 
Index. 

[0126] FIG. 27 shows what kind of branching is per- 
formed when a BD-ROM having the scenarios, shown 
in FIG. 18, recorded thereon is loaded in a core system 
playback device. Depicting the arrows in FIG. 18 using 
the broken line hs1 in FIG. 27 shows that the branching 
in FIG. 27 is no longer valid because the core system 
lacks an element for executing Java objects. The arrow 
js1 in the figure shows alternative branching in place of 
the invalid branching. The alternative branching is per- 
formed with indirect referencing via the index of Title#0. 
The filename of MOVIE object 0 is stored in the Index 
of Title#0, and MOVIE object 0 is read by the playback 
device and executed in this branching. Sg1 is a MOVIE 
object which is executed when branching to MOVIE ob- 
ject 0 is performed. Because a user can implement a 
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game in the MOVIE mode when the BD-ROM is loaded 
in a core-system playback device, it is possible to avoid 
causing the user disappointment about Java/Browser 
modes not being implemented. 
[01 27] Thus concludes an embodiment of the record- 
ing medium according to the present invention. The fol- 
lowing gives an account of an embodiment of a playback 
device according to the present invention. FIG. 28 
shows an internal structure of the playback device ac- 
cording to the present invention. As shown in the figure, 
the playback device comprises: a BD-ROM drive 1 ; a 
track buffer 2; a demultiplexer 3; a video decoder 4; a 
picture plane 5; an audio decoder 6; an image memory 
7; an image plane 8; an image decoder 9; an adder 10; 
a static scenario memory 1 1 ; a playback control engine 
12; a player register 13; a BACKUP memory 14; a dy- 
namic scenario memory 15; a DVD-like module 16; a 
Java module 17; a BROWSER module 18; a UO con- 
troller 1 9; a module manager 20; a dispatcher 21 ; a ren- 
dering engine 22 and a communication unit 23. 
[0128] The BD-ROM drive 1 performs loading/eject- 
ing of a BD-ROM, and accesses the loaded BD-ROM. 
[0129] Thetrackbuffer2 is a FIFO memory that stores 
ACCESS UNITs read from the BD-ROM on af irst-in first- 
out basis. 

[0130] The demultiplexer 3 retrieves ACCESS UNITs 
from the track buffer 2 and demultiplexes these to obtain 
video and audio frames structuring GOPs, and the video 
frames are outputted to the video decoder 4 while the 
audio frames are outputted to the audio decoder 6. A 
subtitle stream is stored in the image memory 7, and the 
Navigation Button Information is stored in the dynamic 
scenario memory 15. Demultiplexion performed by the 
demultiplexers includes conversion processing for con- 
verting TS packets into PES packets. 
[01 31 ] The video decoder 4 decodes the video frames 
outputted from the demultiplexer 3 and writes pictures 
in an uncompressed format on the video plane 15. 
[01 32] The picture plane 5 is a memory for storing un- 
compressed-format pictures. 

[0133] The audio decoder 6 decodes the audio 
frames outputted from the demultiplexer 3 and outputs 
uncompressed-format audio data. 
[01 34] The image memory 7 is a buffer for storing sub- 
title streams read from BD-ROMs, PNG data in the Nav- 
igation Button information, and image files. 
[01 35] The image plane 8 is a memory having a single 
screen capacity area where expanded subtitle streams, 
PNG data, and image files are arranged. 
[0136] The image decoder 9 expands subtitle 
streams, PNG data, and image files storep: in the image 
memory 7, and writes these to the image plane 8. Vari- 
ous menus and subtitles appear on a screen as a result 
of decoding subtitle streams. 

[0137] The adder 10 combines images expanded in 
the image plane 8 with uncompressed-format picture 
data stored in the picture plane 5, and outputs the result. 
An image display shown in FIG. 13B, i.e., a screen dis- 



play in which a CG image (an owl in the figure) is moving 
around next to a window showing videos, is outputted 
as a result of the adder 10 combining images in the im- 
age plane 8 and pictures in the picture plane 5. 

5 [01 38] The static scenario memory 1 1 is a memory for 
storing a current PL and current stream management 
information. A current PL is a PL currently targeted for 
processing from among plural pieces of PL information 
recorded on the BD-ROM. Current stream management 

10 information is a piece of the stream management infor- 
mation currently targeted for processing from among 
plural pieces of the stream management information re- 
corded on the BD-ROM. 

[0139] The playback control engine 1 2 executes var- 

15 ious functions, such as (1) AV playback function, (2) 
PlayList playback functions, and (3) status-acquisition/ 
setting functions in the playback device. The AV play- 
back functions in the playback device, which consist of 
a function group similar to that found in DVD and CD 

20 players, refer to the execution in response to user oper- 
ations of processing, such as starting playback (Play); 
stopping playback (Stop); pausing (Pause-On); releas- 
ing a pause (Pause-Off); releasing a still (Still-Off); 
speed specified fast-forwarding (Forward Play (speed)); 

25 speed specified fast-rewinding (Backward Play 
(speed)); changing audio settings (Audio Change); 
changing subtitle settings (Subtitle Change); and 
changing angle settings (Angle Change). The PL play- 
back functions refer to the execution of Play, Stop, and 

30 other of the AV playback functions in accordance with 
PL information. The playback control engine 12 func- 
tions as Layer 3 (playback controls based on static sce- 
narios) in the layer model by executing these PL play- 
back functions. The playback control engine 12 exe- 

35 cutes the AV playback functions in response to user op- 
erations. On the other hand, the playback control engine 
12 executes functions (2) and (3) in accordance with 
function calls from the DVD-like module 1 6, a Java mod- 
ule 17, and a BROWSER module 18. That is, the play- 

40 back control engine 12 executes its own functions in re- 
sponse to instructions resulting from user operations 
and instructions from higher-level layers in the layer 
model. 

[01 40] The player register 1 3 comprises 32 individual 
45 System Parameter Registers and 32 individual General 
Purpose Registers. The stored values of these registers 
are used in programming as variables SPRMs and 
GPRMs. System Parameter Registers and General Pur- 
pose Registers are managed by playback control en- 
50 gjne 1 2, which is separate from the DVD-like module 1 6, 
Java module 1 7, and BROWSER module 1 8. Therefore, 
it is possible, even when switching in playback modes 
occurs, for the module that implements the playback 
mode after the mode-switch to find the playback status 
55 of the playback device simply by referring to SPRMs(O) 
-(31 ) and GPRMs(0)-(31 ) in the playback control engine 
12. 

[0141] The BACKUP memory 14 is a stack memory 
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for saving stored values of the playback device register 
when one of modules 16 to 18 executes Suspend. The 
stored values of the BACKUP memory 14 are restored 
to the stored values of the register possessed by the 
playback device when one of modules 1 6 to 1 8 executes 
Resume in a dynamic scenario. The stored values of the 
register are stored on afirst-in first-out basis in the event 
that one of modules 16 to 1 8 performed Suspend more 
than two times. If the number of stored values is greater 
than or equal to the number of slots in the stacks, stored 
values that have been saved are overwritten. SPRMs 
saved to the BACKUP memory 14 include language 
codes (Language Code), a number of the current-de- 
coding-target audio stream (Audio Stream Number), a 
number of the current-decoding-target subtitle stream 
(Subtitle Stream Number), a number of the angle set by 
auser(AngleNumber),anumberofthecurrently-being- 
played Title (Title Number), a number of the currently- 
being-played Chapter, a number of the currently-being- 
played PL (PlayList Number), a number of the currently- 
being-played CELL (Playltem Number), a number of the 
button in a selected state (Selected Button), and time 
information showing the current playback point. 
[01 42] The dynamic scenario memory 1 5 is a memory 
storing the current dynamic scenario, and is used for 
processing by the DVD-like module 1 6, Java module 1 7, 
and BROWSER module 18. The current dynamic sce- 
nario is the dynamic scenario currently targeted for 
processing from among the plurality of scenarios re- 
corded on the BD-ROM. 

[0143] The DVD-like module 16, which is a DVD vir- 
tual player that is the main execution body of the MOVIE 
mode, executes current MOVIE objects read to the dy- 
namic scenario memory 15. 

[0144] The Java module 1 7, which is a Java platform, 
comprises a Java Virtual Machine, a configuration, and 
a profile. The Java module 1 7 creates current Java ob- 
jects from ZZZ. CLASS in the dynamic scenario memory 
15, and executes the current Java Objects. The Java 
Virtual Machine converts Java objects described in the 
Java language into native codes for the CPU in the play- 
back device, and has the CPU execute the native codes. 
[0145] The BROWSER module 18 is a browser that 
is the main execution body of the Browser mode, and 
executes current WebPage objects read to the dynamic 
scenario memory 15. Protocols that the BROWSER 
module 1 8 can use include HTTP, IP, ARP, RARP, TCP, 
telnet, SMTP, and ftp. The DVD-like module 16, Java 
module 17, and BROWSER module 18 are all resident 
programs that are preimplemented in the playback de- 
vice. 

[0146] The UO controller 1 9 detects user operations 
performed with respect to a remote controller and a front 
panel of the playback device, and outputs information 
indicating detected user operations (hereinafter, "UO") 
to the module manager 20. 

[0147] The module manager 20 holds an Index Table 
read from the BD-ROM and performs mode manage- 
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ment and branch controls. The mode management per- 
formed by the module manager 20 refers to the alloca- 
tion of modules; namely which of modules 1 6 to 1 8 is to 
execute dynamic scenarios. The principle of module al- 

s location is that DVD-like module 16 executes dynamic 
scenarios. This principle is upheld even if in the case of 
branches resulting from intra-modes (i.e. branches with- 
in the same mode). An exception is when inter-mode 
branching occurs (i.e. branching between different 

10 modes) . When branching from a MOVI E object to a Java 
object or a Webpage object occurs, the Java module 1 7 
or BROWSER module 18, respectively, executes the 
current object. 

[0148] Branch controls performed by the module 

15 manager 20 include identifying branch-destination dy- 
namic scenarios, reading the specified dynamic scenar- 
ios to memory, and having one of the DVD-like module 
16, Java module 17, and BROWSER module 18 exe- 
cute the dynamic scenarios. Identification is necessary 

20 particularly when branch-destination dynamic scenarios 
are specified using an indirect referencing format. The 
identification is carried out by referring to the b ranch - 
destination labels of branch commands and retrieving 
filenames from indexes corresponding to the labels. A 

25 judgment as to whether mode switching is necessary is 
conducted in conjunction with this identification. The 
judgment on the mode-switching necessity is performed 
by referring to a file extension stored in the Index corre- 
sponding to the branch-destination label. The extension 

30 has been set to "MOVIE" when the branch-destination 
dynamic scenario is the MOVIE mode, the extension 
has been set to "CLASS" when the branch-destination 
dynamic scenario is the Java mode, and the extension 
has been set to "HTML" or "XML" when the branch-des- 

35 tination dynamic scenario is the Browser mode. Thus, 
the extension stored in the Index reveals whether mode 
switching is necessary. If mode switching is necessary, 
the branch-destination dynamic scenario is read to 
memory, and a mode-transition request is outputted to 

40 the module that implements the post-switching mode. 
As a result of the mode-transition request being output- 
ted, the module implementing the post-switching mode 
executes the branch-destination dynamic scenario in 
memory. 

45 [0149] The dispatcher 21 chooses only UOs appropri- 
ate to the current mode of the playback device, and 
passes chosen UOs on to the module for implementing 
the mode. For example, if UOs of "left", "right", "up", 
"down" or "activate" are received during the execution 

so of the MOVIE mode, the dispatcher 21 outputs those 
UOs to the module executing the MOVIE mode. This is 
because these UOs are only required for menu behavior 
in the MOVIE mode, and are not required by Java and 
Browser modes. 

55 [0150] The rendering engine 22 that has infrastruc- 
ture software, such as Java3D and OPEN-GL, renders 
CGs according to instructions from the Java module 1 7, 
and outputs the rendered CGs to the image plane 8. 
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[01 51 ] The communication unit 23 executes commu- 
nication procedures based on TCP/IP according to in- 
structions from BD-ROMs, and accesses websites. 
Thus concludes the description of the playback device 
elements. The module manager 20 will now be de- 5 
scribed in detail. 

[01 52] The module manager 20 can be implemented 
by having a general purpose CPU read programs for 
performing the processing procedures shown in FIGs. 
29 and 30. FIGs. 29 and 30 are flowcharts showing the 10 
processing procedures performed by the module man- 
ager 20. Branch controls performed by the module man- 
ager 20 will now be described with reference to these 
flowcharts. In the FIG. 29 flowchart, the module manag- 
er 20 retrieves a filename from the FirstPlay Index in the 1$ 
Index Table (Step S1), sets the current mode to the 
MOVIE mode (Step S2), sets the dynamic scenario hav- 
ing the retrieved filename as the current dynamic sce- 
nario (Step S3), reads the current dynamic scenario i to 
memory (Step S4), and executes the current dynamic 20 
scenario in memory (Steps S5 to S10). 
[0153] Steps S4 to S10 are executed whenever the 
current dynamic scenario is newly set. 
[0154] Steps S5 to S10 form a loop process in which 
the processing of Steps S6 to S1 0 is repeated for each 25 
command structuring a scenario. The "V in the flow- 
charts is a variable that identifies processing targets 
from among the commands structuring a dynamic sce- 
nario. The loop process involves initializing variable x 
(Step S5), having the module of the current mode exe- 30 
cute the command x in the current dynamic scenario / 
(Step S6), performing the judgment processing defined 
in Steps S7 and S8, and then incrementing the variable 
x (Step S10), before returning to Step S6. Since 
processing of returning to Step S6 with an increment of 35 
the variable x is repeated, the processing of Steps S6 
to S1 0 is repeated for aii of the commands structuring 
the scenario. If a UO occurs during execution of the loop 
process (Step S7), the module manager 20 executes 
UO dispatch processing (Steps S31 to S33 in FIG. 30), *o 
and then returns to Step S8. UO dispatch processing is 
that, when a UO occurred during command execution 
is one of "left", "right", "up", "down" or "activate" (Step 

531) and the current mode is the MOVIE mode (Step 

532) , the UO is outputted to the module that executes <5 
the current mode. When a UO occurred during com- 
mand execution is a UO other than "left", "right", "up"; 
"down" and "activate", the UO is directly outputted to the 
module that executes the current mode (Step S33). 
When a UO occurred during command execution is a 50 
UO other than "left", "right", "up", "down" and "activate", 

but the current mode is not the MOVIE mode, the oc- 
curred UO is not outputted to the module. Thus con- 
cludes the description of dispatch processing. 
[0155] While the dispatch processing is performed, 55 
processing of Steps S6 to S10 is repeated. In the loop 
process of Steps S6 to S1 0, switching of the current dy- 
namic scenario that is a processing target is performed 



when judgment in Step S8 is YES. Step S8 is a judgment 
of whether the command xis a branch command. If Step 
S8 is YES, the module manager 20 returns to Step S4 
after setting the current dynamic scenario to a new dy- 
namic scenario in Steps S11 to S20. Herewith, the new 
dynamic scenario will be read to memory and executed. 
[0156] Processing of Steps S11 to S23 will be now de- 
scribed below. This processing involves branch con- 
trols, and differs depending on the judgment results of 
Steps S11 , S14, S19, and S22. Step S11 is a judgment 
of whether a branch destination shown by a branch com- 
mand is described using a Title label. If YES, the module 
manager 20 acquires the branch-destination label Titlej 
(Step S12) after going through the Step S22 judgment, 
and retrieves filenamej from Indexi of Titlej in the Index 
Table (Step S13). If NO, the module manager 20 re- 
trieves filenamej showing the branch destination (Step 
S21). 

[0157] Step S14 is a judgment of whether the branch 
command is a Call command or a Jmp command. If a 
Call command, the module manager 20 suspends the 
current dynamic scenario / and saves the variable x 
(Step S15). If a Jmp command, the module manager 20 
discards the currenf dynamic scenario i (Step S16). 
[0158] Having passed through the above processing, 
the module manager 20 sets the dynamic scenario iden- 
tified from filenamej as the current dynamic scenario i 
(Step S17), and sets the playback mode identified from 
the retrieved extension as playback mode k (Step S1 8). 
After these settings, the module manager 20 executes 
Step S1 9. Step S1 9 is a judgment of whether the play- 
back mode k is the current mode. If not the same, the 
module manager 20 set the playback mode fras the cur- 
rent playback mode (Step S20), and transfers to Step 
S4. After that, the processing of Steps S4 to S10 is re- 
peated with respect to the newly set current dynamic 
scenario. Step S22 is a judgment of whether the play- 
back device is a core system or a full system, and if a 
core system, the module manager 20 retrieves the 
filename from Index of Trtle#0, and sets this as the 
branch destination (Step S23). 
[0159] The requirement for ending the loop process 
of Steps S4 to S1 0 is that a judgment in Step S9 be YES. 
If the command x is the final command in the dynamic 
scenario / (Step S9: YES), a judgment is conducted as 
to whether a Resume, command exists at the end of the 
dynamic scenario / (Step S34). If NO, the processing 
shown in the flowcharts is terminated. If there is a 
Resume command attached at the end of the dynamic 
scenario /, the module manager 20 sets the suspended 
dynamic scenario as dynamic scenario / (Step S35), 
sets the mode of the dynamic scenario / as the current 
mode (Step S36), has the module in the current mode 
resume the dynamic scenario / being suspended (Step 
S37), sets the variable xback to a value before the dy- 
namic scenario /suspended (Step S38), and then trans- 
fers to just before Step S10 of the loop process com- 
posed of Steps S6 to S1 0. Thus concludes the descrip- 
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tion of processing procedures performed by the module 
manager 20. 

[01 60] The playback control engine 1 2 can be imple- 
mented by having a general purpose CPU read pro- 
grams for performing the processing procedures shown 5 
in FIG. 31 . FIG, 31 is a flowchart showing execution pro- 
cedures of a PLPlay function performed by the playback 
control engine 12. In the flowchart, a processing target 
PL is denoted as n PLx", a processing target CELL is de- 
noted as "CELLy" , a processing target ACCESS UNIT io 
as "ACCESS UNITv". The flowchart comprises the fol- 
lowing procedures: setting the PL specified by an argu- 
ment of the PLPlay function as PLx (Step S41), reading 
PLx to memory (Step S42), identifying the processing 
target CELL (Steps S43 to S47), and reading the AC- 15 
CESS UNITS structuring the CELL (Steps S48 to S51 ). 
[0161] Step S43 is a judgment of whether there is a 
CELL argument specification. If there is no argument 
specification, the playback control engine 12 sets CEL- 
Ly as the head CELL of PLx (Step S44), and sets CELLz 20 
as the last CELL of PLx (Step S45). CELLz is a CELL 
for specifying the end of the reading range. 
[0162] If there is an argument specification, the play- 
back control engine 12 sets CELLy to the argument 
specified CELL (Step S46), and sets CELLz to the same 25 
argument specified CELL (Step S47). Both CELLy and 
CELLz are set to the argument specified CELL because 
it is only necessary to read this CELL in the case of a 
CELL being specified by an argument. 
[0163] Steps S48 to S53 show the reading of AC- 30 
CESS UNITs structuring CELLy, and a decoding proce- 
dure. This procedure involves: identifying ACCESS 
UNITv including the In-point video frame of CELLy from 
TMAP (Step S48); instructing the BD-ROM drive 1 to 
read ACCESS UNITv (Step S49); instructing the video 35 
decoder 4 to decode the video frames included in AC- 
CESS UNITv (Step S52) after going through judgments 
of Steps S50 and S51 ; and setting ACCESS UNITv to 
the next ACCESS UNIT (Step S53). After that the 
processing of Steps S49 to S53 is repeated for all of the 40 
ACCESS UNITs belonging to CELLy. 
[0164] Step S50 is a judgment of whether ACCESS 
UNITv includes the IN-point video frame. If the In-point 
video frame is included (Step S50: YES), the playback 
control engine 1 2 directs the video decoder 4 to conduct 45 
decoding from the In-point video frame to the last vide 
frame of ACCESS UNITv (Step S54), and transfers to 
Step S52. 

[0165] Step S51 is a judgment of whether Out-point v 
includes the Out-point video frame of CELLy. If the Out- so 
point video frame is included (Step S51 : YES), the play- 
back control engine 12 instructs the video decoder 4 to 
conduct decoding from the head video frame to the Out- 
point video frame in ACCESS UNITv (Step S55) t and 
conducts a judgment of Step S56. Step S56, which is 55 
the final judgment in the f lowchart, judges whether CEL- 
Ly is now CELLz. If Step S56 is YES, the playback con- 
trol engine 12 terminates the flowchart. Otherwise, the 



playback control engine 1 2 sets CELLy to the next CELL 
(Step S57) before returning to Step S48. After that, the 
processing of Steps S48 to S57 is repeated until the 
judgment of Step S56 becomes YES. Thus concludes 
the description of the processing procedures performed 
by the playback control engine 12. 
[0166] Since it is possible to have playback devices 
execute, in the enhanced modes, games and the like 
that harnesses characteristic features of Java Virtual 
Machines and browsers, the present embodiment as 
described above is able to enhance the added value of 
actual video data. In addition, since the branch destina- 
tion is specified by Indirect referencing via a table in the 
event of branching from the MOVIE mode to the en- 
hanced mode, it is possible to realize the operation of 
changing branch destinations of when BD-ROMs are 
loaded on playback devices having a Java Virtual Ma- 
chine and a browser from those of when they are loaded 
on playback devices not having those applications by 
designing description contents of the table. As a result 
of the change in branch targets, it is possible to close a 
path for branching to enhanced-mode programs when 
the BD-ROM is loaded on core system playback devices 
not having a Java Virtual Machine and a browser, and 
thus operation assurance of the recording medium ac- 
cording to the present invention can be realized for any 
type of playback devices. 

2. Second Embodiment 

[01 67] The first embodiment provides an explanation 
of the Java object that takes over a register setting value 
set in a MOVIE object and performs an operation. On 
the other hand, a second embodiment describes a Java 
object that executes PL playback and performs various 
playback controls in synchronization with the PL play- 
back. 

[0168] FIG. 32 shows a file structure of a BD-ROM 
according to the second embodiment. What is new in 
the figure is that YYY.Mark (PLMark) and XXX.Mark 
(ClipMark) have been added. 

[0169] PLMarks are information indicating sections 
that a playback device is to perform extended controls 
during PL playback. For the filename "YYY" in YYY. 
Mark, a name the same as that of the PL to which the 
PLMark corresponds is used. That is, the filename of 
the PLMark in. the figure being "YYY" indicates that the 
PLMark corresponds to the PL (YYY. PL). 
[0170] ClipMarks are information indicating sections 
that a playback device is to perform extended controls 
during AV stream playback. For the filename "XXX" in 
XXX.Mark, a name the same as that of the AV stream 
to which the ClipMark corresponds is used. That is, the 
filename of the ClipMark in the figure being "XXX" indi- 
cates that the ClipMark corresponds to the AV stream 
(XXX.M2TS). 

[0171] The difference between ClipMarks and 
PLMarks is described below. ClipMarks specify sections 
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for extended controls with respect to AV streams, while 
PLMarks specify sections with respect to PLs. 
[0172] For example, in the case when two pieces of 
PL information are defined for one AV stream as shown 
in FIG. 11 , if an extended controi section is specified by 5 
a ClipMark, this specification works on both pieces of 
the PL information specifying the AV stream. On the oth- 
er hand, if an extended control section is specified by a 
PLMark, the extended control specification works only 
on a PL corresponding to the PLMark. If a PL corre- 10 
sponding to the PLMark is PL#1 , the specification works 
only on PL#1 , and does not work on PL#2. In other word, 
when the extended control section is specified by a Clip- 
Mark, all PLs included in the AV stream are subject to 
the ClipMark, while when the extended control section 1$ 
is specified by a PLMark, only a PL corresponding to the 
PLMark is subject to the PLMark. This is the difference 
between ClipMarks and PLMarks. 
[0173] Extended controls in the present embodiment 
involve generating events in a playback device. In order 20 
to generate events, PLMarks and ClipMarks have a 
common data configuration shown in FIG. 33. FIG. 33 
shows a data structure common to a PLMark and a Clip- 
Mark. As shown in the figure, a PLMark, which compris- 
es the number of events (Number) and individual events 25 
(Event#1-Event#m), defines events to be generated 
during playback. Each event (Event#) shows a type of 
event (Type), an event ID (ID), a time when the event 
occurs (Time), and a duration of the time period when 
the event is valid (Duration). 30 
[0174] Events defined with such a data configuration 
include TimeEvents and UserEvents. ATimeEvent is an 
event that occurs when the current playback position 
reaches a predetermined point of time T on the time axis 
of PL playback. A UserEvent is an event that occurs 35 
when the current playback position reaches a predeter- 
mined time period and an operation is carried out by a 
user during the time period. 

[0175] How to describe a PLMark for defining a 
TimeEvent that appears during playback of PL#1 is ex- 40 
plained with reference to FIG. 34A. The time axis at the 
bottom of the figure shows a time axis of PL#1 playback. 
Here, assume the case where TimeEventExl that oc- 
curs at Time t1 on the time axis is defined. PLMarkmtl 
in the figure is an exemplified description of the PLMark 45 
for defining a TimeEvent. As to the PLMark, the Type 
item is described as "TimeEvent", the ID item is de- 
scribed as "Ex1 ", the Time item is described as n t1 ", and 
the Duration item is described as "0". The arrow in the 
figure shows the TimeEvent occurring when Time t1 is so 
reached. As a result of the TimeEvent occurrence, the 
event handler in the figure is driven. 
[0176] On the other hand, FIG. 34B shows an exem- 
plified description of a PLMark for generating a 
TimeEvent at intervals of Tfrom Time t1 on the time axis. 55 
FIG. 34B differs from FIG. 34A in the Duration item of 
the PLMark is described as T. With the description in 
the Duration item, the TimeEvent is generated at inter- 



vals of T after Time t1 . 

[01 77] How to describe a PLMark for defining a User- 
Event during PL#1 playback is explained with reference 
to FIG. 35. The time axis shown in the middle of the fig- 
ure shows a playback time axis for PL#1 playback. The 
current playback point on the time axis is shown in 
SPRM(10). Here, assume a case where UserEventEvI 
that becomes valid for a time period T1 from Time t1 on 
the time axis is defined. PLMarkmt2 in the figure is the 
PLMark that defines the UserEvent. As to the PLMark, 
the Type item is described as "UserEvent", the ID item 
is described as "Ev1 ", the Time item is described as "t1 ", . 
and the Duration item is described as "TV. The remote 
controller rm1 in the figure is a device for receiving user 
operations, and the arrow uv1 indicates a UO that oc- 
curs in response to a push down of the ENTER key on 
the remote controller. When a UO occurs during the time 
period T1 from Time t1 , UserEventEvI occurs based on 
the UO. As a result of the UserEvent, the event handler 
in the figure is driven. Thus concludes the description of 
events defined by PLMarks. Here, a description of 
events defined by ClipMarks is omitted. Because Clip- 
Marks define events that occur during AV stream play- 
back whereas PLMarks defining events that occur dur- 
ing PL playback, event definitions of ClipMarks are not 
very different from those of PLMarks. 
[0178] Next is described a Java object according to 
the second embodiment. A member function of ZZZ. 
CLASS in the second embodiment is an event handler 
driven by events generated by a playback device during 
PL playback. The following describes event handlers, 
which are member functions of Java objects, with the 
aid of specific examples. FIG. 36 shows examples of 
event handlers driven by TimeEvents, while FIG. 37 
shows an example of an event handler driven by a User- 
Event. 

[01 79] In the exemplified descriptions shown in FIGs. 
36 and 37, decoding of image data shall be performed 
using the following rendering function. 
[0180] Rendering function: rendering PNG data in the 
image plane 

Draw(File, X, Y) 

File: a filename storing the PNG data 
X: X-coordinate 
Y: Y-coordinate 

[0181] Image-plane-clear function: clearing a speci- 
fied area in the image plane 
Clear (X, Y, W, H) 

X: X-coordinate 
Y: Y-coordinate ^ 
W: width in the X direction 
H: width in the Y direction 

[0182] The handler hd1 in FIG. 36 is a handler for ex- 
ecuting function{GPRM(0)=1; ... Draw("2white.png", 
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330, 200);} when TimeEvent t1 occurs. TimeEvent t1 is 
an event that occurs immediately after the start of PL#1 
playback (this is called Time t1 ). The function of the han- 
dler hd1 involves: setting "1" to GPRM(0), (GPRM(0) 
=1 ); rendering " 1 black.png" at the coordinates (10, 200), s 
(Draw(lblack.png,1 0,200)); and rendering '^white.png" 
at the coordinates (330, 200), (Draw(2white.png. 
330,200)). "1 black.png" is image data of a button in se- 
lected state, "2white.png w is image data of a button in 
normal state. The graphic image ig1 in FIG. 36 is a 10 
graphic image rendered by the event handler in the fig- 
ure. The buttons bn1 and bn2 in the figure are obtained 
by decoding "1 black.png" and M 2white.png", respective- 
ly. GPRM(0) indicates which button of these two is in 
selected state. GPRM(0) being set to "1 " means that, of 15 
the buttons bn1 and bn2, the button bn1 is set in select- 
ed state. 

[0183] The handler hd2 is a handler for executing 
function{PlayPL: (-,-,0)} when TimeEvent t2 occurs. 
TimeEvent t2 is an event that occurs immediately before 20 
the end of PL#1 playback (this is called Time t2). The 
function of the handler hd2 involves executing "PlayPL 
(-,-,0)". "(-.-.O)" means "from the head Cell of the PL be- 
ing currently played". 

[01 84] The handler hd3 in FIG. 37 is a handler driven 25 
when a UserEvent occurs during PL#1 playback. 
"<event handler id= UserEvent k1>" of the handler hd3 
indicates that the content following "f unction{" is execut- 
ed when UserEvent k1 occurs. 

[01 85] The content following "fu nctionf is composed 30 
of two IF statements. The conditional expression of the 
first IF statement sets forth a condition of GPRM(0) be- 
ing "1" and SPRM(8) being Right, (GPRM(0)==1 && 
SPRM(8)==Right). When the condition is true, "2" will 
be set to GPRM(O), (GPRM(0)=2;); "1 white.png" is ren- 35 
dered at the coordinates (10, 200), (Draw(1 white.png, 
10,200)); and "2black.png n is rendered at the coordi- 
nates (330, 200), (Draw(1black.png,330,200). 
[01 86] The image ig2 in FIG. 37 is an image rendered 
when the condition is true. When the condition of the IF *o 
statement is true, the right button bn2 is set in selected 
state as the image jg2. The graphic image ig1 of FIG. 
36 is shown next to the image jp2. The comparison of 
these images reveals that the event handler switches 
buttons in selected state according to the UserEvent oc- *s 
currence. 

[01 87] The ELSE clause in the IF statement involves 
judging whether or not the condition of SPRM(8) being 
OK is true. If the condition is true, the second IF state- 
ment will be executed. so 
[0188] The condition of the second IF statement, 
which is ,, (GPRM(0)==1) M , is true, the IF statement ex- 
ecutes playback of CeIMM in PL#2 from the beginning, 
(PlayPI(PL#2,Cell#1 ,0)). If the condition is false, the IF 
statement executes playback of Cell#1 in PL#3 from the 55 
beginning, (PlayPI(PL#3,Cell#1 ,0)). 
[0189] FIG. 38 shows conditional branching as a re- 
sult of event handlers by combining pictures played in 



the PLs and images rendered by the event handlers of 
FIGs. 36 and 37. Since the event handler driven by 
TimeEvent t1 is a handler for combining buttons with pic- 
tures, the image ig1 (including the buttons bn1 andbn2) 
is combined with respectto the first picture pd , the mid- 
dle picture pc2, and the last picture pc3 in the PL, and 
the combined images are displayed. Since the event 
handlerdriven by TimeEvent t2 is a handlerfor returning 
to the beginning of the Cell after the last picture data of 
the Cell in the PL is played, the first picture data is dis- 
played, as indicated by the arrow py1 , after the last pic- 
ture data is displayed, and the buttons are combined 
with the first picture data. Unless there is a user opera- 
tion, display of such combined images is repeated. If a 
UserEvent occurs as a result of a push down on an ar- 
row key by a user, as indicated by ky1 , the image jg2 is 
combined with each picture structuring the AV stream, 
instead of image ig1. 

[0190] If a user pushes the Enter key down while the 
image ig1 is displayed, "PlayPL(PL#2,Cell#1,0) M in the 
event handler hd3 is executed, as indicated by the arrow 
ey1 , to play CeIMM in PL#2. 

[0191] If a user pushes the Enter key down while the 
image ig2 is displayed, n PlayPL(PL#3,CelI#1,0)" in the 
event handler hd3 is executed to play Cell#1 in PL#3 as 
indicated by the arrow ey2. 

[0192] The use of event handlers allows to easily de- 
scribe a playback procedure in which a single Cell is re- 
peatedly played until a user operation is conducted, and 
branching is performed according to a button as a result 
of a user operation. 

[0193] With the use of such event handlers, controls 
similarto men u behavior realized in DVDs can be readily 
described by using the Java language that program- 
mers are used to writing in. With a further development 
of the event handlers, it is possible to realize elaborated 
menu display where CGs operate in place of buttons, 
for example. Accordingly, the range of expressions in- 
volved with movie productions will be expanded. 
[0194] Thus concludes the description of the improve- 
ment in Java objects according to the second embodi- 
ment. Next are described improvements in the playback 
device according to the present embodiment. In order 
to generate TlmeEvents and UserEvents described 
above, it is preferable to have the playback control en- 
gine 12 conduct processing procedures as shown in 
FIG. 39. 

[0195] FIG. 39 shows processing procedures of the 
playback control engine 1 2 according to the second em- 
bodiment. What is new in the flowchart is that two judg- 
ing steps of Steps S60 and 62 are placed in a series of 
processing where ACCESS UNITs structuring a CELL 
are read and decoded (Steps S49 to S53). Step S60 is 
a judging step of whether, in PL playback, a TimeEvent 
having the current playback point as its occurrence time 
has been defined by a PLMark or a ClipMark. If Step 
S60 is YES, the TimeEvent is generated (Step S61 ) be- 
fore the playback control engine 12 transfers to Step 
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S51 . Herewith, an event handler having the TimeEvent 
as a driving requirement will be driven. 
[0196] Step S62 is a judging step of whether aUO has ^ 
occurred. If Step S62 is YES, the playback control en- 
gine 1 2 judges whether or not the current playback point s 
is during the time period where the UO is valid, referring 
to the PLMark or the ClipMark (Step S63). If it is within 
the time period, the playback control engine 12 gener- 
ates the UserEvent (Step S64) and returns to Step S51 . 
[0197] According to the present embodiment as de- to 
scribed above, since events are generated according to 
the progress of playback point while the playback con- 
trol engine 12 is performing PL playback, event handlers 
having TimeEvents and UserEvent as the driving re- 
quirements can be driven in the Java mode. Herewith, ts 
games closely synchronized with the video contents can 
be described by using the Java language. 

3. Third Embodiment 

20 

[0198] Whereas the second embodiment describes 
event handlers driven by events defined by PLMarks 
and ClipMarks, a third embodiment relates to improve- 
ments in the case where behaviors of member functions 
defined by PLMarks and ClipMarks are synchronized 25 
with AV playback functions. The AV playback functions 
in the playback device consist of a function group similar 
to that found in DVD and CD players, and include start- 
ing playback (Play); stopping playback (Stop); pausing 
(Pause-On); releasing a pause (Pause-Off); releasing a 30 
still (Still-Off); speed specified fast-forwarding (Forward 
Play (speed)); speed specified fast-rewinding (Back- 
ward Play (speed)); changing audio settings (Audio 
Change); changing subtitle settings (Subtitle Change); 
and changing angle settings (Angle Change). 35 
[0199] The playback device generates an event ac- 
cording to a. function to be executed when a user in- 
structs such functions cited above. The playback device 
generates a Backward Event when a user instructs it to 
execute the fast-rewind function; the playback device 40 
generates a Fast-forward Event when a user instructs it 
to execute the fast-forward function; and the playback 
device generates a Pause Event when a user instructs 
it to execute the pause function. Driving event handlers 
with these events has the following significance. Play- 
back operations are conducted on the time axis of PL 
playback, while operations performed by a Java Virtual 
Machine do not have a concept of a time axis. Since 
Java Virtual Machine's operations are not based on a 
time axis, it is required to let the Java Virtual Machine 50 
know the progress of PL playback with some sort of 
means in order to synchronize PL playback controls with 
operations of the Java Virtual Machine. Events to let the 
Java Virtual Machine know PL playback controls on the 
time axis are Backward Events, TimeEvents, and Pause 55 
Events. 



3. 1 Backward Events 

[0200] Backward Events are events for driving event 
handlers, in the case where fast-rewind operations are 
performed by a user, in response to the fast- rewind op- 
erations being made. Technical significance of introduc- 
ing Backward Events is described below. FIG. 40 is a 
schematic diagram for illustrating the technical signifi- 
cance of Backward Events. In the figure, assume here 
that a member function of the Java object is a program 
for operating a CG of Character A on screen. When it is 
desired to drive the member function Time t1 after the 
start of PL playback, a TimeEvent that occurs when 
Time t1 elapses may be preferably defined with a 
PLMark, and the above-cited program can be described 
as an event handler driven by the TimeEvent. 
[0201] Driving an event handler with such a 
TimeEvent presents a problem when irregular playback 
involving a sequence of "rewinding and playing" is re- 
peated any number of times. In this case, the TimeEvent 
in which the Time t1 elapses occurs over and over, which 
results in multiple CGs appearing on screen where only 
one CG should appear. bg1 in FIG. 40 indicates a CG 
rendered by a handler due to the playback point having 
reached Time t1 , while bg2 indicates a CG rendered by 
the handler due to the playback point having reached 
Time t1 again after a rewind. Two CGs are actually ren- 
dered where there should be only one CG rendered, and 
therefore images appearing on the screen become odd. 
In order to avoid presenting such odd looking images 
on the screen, it is preferable to have described an op- 
eration in the Java object so as to clear the CG appear- 
ing on the screen in the event where the playback time 
once extended beyond Time t1 and has reached Time 
t1 again after a rewind. This can be realized by causing 
the playback device to generate a Backward Event (bw1 
in the figure) when a rewind operation is performed and 
having defined, in ZZZ.CLASS, an event handler that is 
driven by the Backward Event. When a rewind operation 
is performed and TimeEvent t1 occurs once again, only 
one CG will appear on the screen as a result of having 
the event handler to clear the CG on the screen, even 
when irregular playback involving a sequence of "re- 
winding and playing" is repeated several times. 
[0202] FIGs. 41 and 42 show examples of screen dis- 
plays related to the case when an event handler driven 
by a Backward Event is used. FIG. 41 A is an example 
of screen display obtained at a time of PL playback in 
the Java mode being started, while FIG. 41 B is an ex- 
ample of screen display of when the PL playback point 
has reached Time t1 . The PL playback point having 
reached Time t1 results in the occurrence of the 
TimeEvent, and the event handler is driven by the 
TimeEvent. The owl in the figure is a CG rendered as a 
result of the event handler of the Java object being driv- 
en. 

[0203] FIG. 41 C is an example of screen display of 
when the PL playback point has reached Time t2. As- 
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sume here that a user performed a rewind when the 
playback point reached Time t2. FIG, 42A shows an ex- 
ample of screen display of when the PL playback point 
has reached Time t1 after the rewind. When the PL play- 
back point has reached Time t1 , the owl in the figure is s 
cleared. This is for preventing the image of the owl from 
being rendered over again as described above. Assume 
that the playback point subsequently reached Time to 
due to the rewind (FIG. 42B), and a user performed nor- 
mal playback once again. FIG. 42C shows an example w 
of screen display of when the PL playback point has 
reached Time t1 again. Since the CG was cleared when 
the rewind was performed, here a CG appearing on the 
screen is only one even if a CG is re-rendered as a result 
of the PL playback point having reached Time t1 . 15 
[0204] Note that, although a CG is cleared by a Back- 
ward Event in the present embodiment, the CG of the 
owl may be alternatively cleared by defining, in a 
PLMark, a TimeEvent that occurs at Time t2 so that 
TimeEvents occur in the order of: TimeEventtl -» 20 
TimeEventt2 -> TimeEventtl . 

3.2 TimeEvents 

[0205] TimeEvents described in the second embodi- 25 
ment is characterized by occurring at time intervals ac- 
cording to the speed of fast-forward when playback is 
performed at fast speed. FIG. 43 schematically shows 
TimeEvent occurrences during fast-forwarding. In the 
figure, the TimeEvents occur at a time interval dr1 . The 30 
time interval depends on a user's specification on the 
fast-forward speed, and the interval becomes shorter as 
the PL playback speed is faster while the interval be- 
comes longer as the playback speed is slower. Thus, 
the TimeEvents occur at shorter intervals when the PL 35 
playback speed is faster. Contrarily, the TimeEvents oc- 
cur at longer intervals when the PL playback speed is 
slower. Java objects are able to find whether the PL 
playback is proceeding fast or slow from the time interval 
of the TimeEvent occurrences being longer or shorter. *o 
Herewith, a program can be arranged so that CG motion 
is changed when the PL playback proceeds fast or slow. 
As a result, it is possible to precisely time-synchronize 
CG motion with PL playback. 

[0206] FIG. 44 shows an example of screen display 45 
of when an event handler driven by TimeEvents in ac- 
cordance with a fast-forward. FIG. 44A is an example of 
screen display obtained at a time of PL playback In the 
Java mode being started, while FIG. 44B is an example 
of screen display of when the PL playback point has 50 
reached Time t1 . The TimeEvent occurs as a result of 
the PL playback point having reached Time t1 , and the 
event handler is driven by the TimeEvent. The owl in the 
figure is a CG rendered as a result of the event handler 
being driven. FIG. 44C shows an example of screen dis- 55 
play of when a fast-forward is performed. Due to the fast- 
forward being performed, the time interval of the 
TimeEvent occurrences changes. The Java object 



changes the motion of the CG in the figure according to 
the change in the interval. 

[0207] The owl flying in FIG. 44C illustrates one ex- 
ample of changing a method of CG rendering. By chang- 
ing the CG rendering method according to the interval 
of TimeEvent occurrences, it is possible to precisely 
synchronize the Java object operations with PL play- 
back, even if the PL is played at fast speed. Note that 
the screen display with transverse lines in FIG. 44 ex- 
aggeratingly depicts the fast-forward PL playback in 
progress, likened to VTR playback. In an actual 
BD-ROM fast-forward, such transverse lines do not ap- 
pear on screen. Here, it is preferable to clear CGs from 
the screen when the fast-forward is performed at a high 
speed, for example, of 10 times faster than the normal 
playback speed. 

3.3 Pause Events 

[0208] Pause Events are events that occur in the play- 
back device when pause operations are performed. 
FIG. 45 schematically shows a Pause Event occur- 
rence. By describing an event handler so that the play- 
back device operation is stopped at the occurrence of 
such a Pause Event, it is possible to eliminate discrep- 
ancies in operations where, for example, CG motion is 
in progress while PL playback being stopped. 
[0209] By defining, as member functions, event han- 
dlers that operate as a result of the above-described 
events, it is possible to supply viewers with high-grade 
movie works in which operations of Java objects pre- 
cisely synchronize with PL playback. 
[0210] According to the present embodiment as de- 
scribed above, since processing of Java objects is 
changed based on the current playback point on the 
playback time axis and the speed of the playback 
progress, it is possible to make motion of CGs rendered 
by Java objects more realistic. 

4. Fourth Embodiment 

[021 1] A fourth embodiment relates to improvements 
in realizing, on a BD-ROM, menu controls similar to 
those of a DVD. FIG. 46 shows a menu hierarchy real- 
ized by a BD-ROM. The menu hierarchy in the figure 
has a structure where TopMenu is at the highest level, 
and TitleMenu, SubTltleMenu, and AudioMenu, all of 
which are subordinate menus of the TopMenu, can be 
selected from the TopMenu. The arrow sw1 , sw2, and 
sw3 in the figure schematically show menu switching by 
button selection. The TopMenu is a menu having but- 
tons arranged thereon for receiving either an audio se- 
lection, a subtitle selection, or a Title selection to per- 
form (buttons sn1 , sn2, and sn3 in the figure). 
[0212] The TitleMenu is a menu having buttons ar- 
ranged thereon for receiving a selection from movie 
works (Titles), such as a cinema version, a director's cut 
version, and a game version. The AudioMenu is a menu 
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having buttons thereon for receiving whether audio play- 
back is to be in Japanese or English, and the Subtitte- 
Menu is a menu having buttons thereon for receiving 
whether subtitle display is to be in Japanese or English. 
[0213] FIG. 47 shows MOVIE objects for operating 
menus having such a hierarchy. 
[021 4] A FirstPlay object (FirstPlay OBJ) is a dynamic 
scenario describing a startup procedure taken when a 
BD-ROM is loaded in a playback device. The square 
boxes depicting the FirstPlay object represent com- 
mands for executing the setup procedure. The last com- 
mand of the FirstPlay object is a branch command, and 
sets a TopMenu object as its branch destination. 
[0215] The TopMenu object (TOPMenu OBJ) is a dy- 
namic scenario for controlling the behavior of the Top- 
Menu. The square boxes depicting the TopMenu object 
are schematic representations of individual commands 
showing the control procedure. These commands in- 
clude commands for changing a state of buttons in the 
TopMenu in response to operations from a user, and 
branch commands for branching in response to confir- 
mation operations made for buttons. The branch com- 
mands realize menu switching from the TopMenu to the 
TltleMenu, from the TopMenu to the SubTltleMenu, and 
from the TopMenu to the AudioMenu. 
[0216] An AudioMenu object (AudioMenu OBJ) is a 
dynamic scenario for controlling the behavior of the Au- 
dioMenu. The square boxes structuring the AudioMenu 
object are schematic representations of individual com- 
mands showing the control procedure. These com- 
mands include commands for changing a state of but- 
tons in the AudioMenu in response to operations from 
a user, and commands for updating SPRMs used in au- 
dio settings in response to confirmation operations 
made for buttons. 

[0217] A SubTltleMenu object (SubtitleMenu OBJ) is 
a dynamic scenario for controlling the behavior of the 
SubTltleMenu. The square boxes structuring the SubTl- 
tleMenu object are schematic representations of individ- 
ual commands showing the control procedure. These 
commands include commands for changing a state of 
buttons in the SubTltleMenu in response to operations 
from a user, and commands for updating SPRMs used 
in subtitle setting in response to confirmation operations 
made for buttons. 

[0218] A TltleMenu object (TrtleMenu OBJ) is a dy- 
namic scenario for controlling the behavior of the Title- 
Menu. The square boxes structuring the TltleMenu ob- 
ject are schematic representations of individual com- 
mands showing the control procedure. These com- 
mands include commands for changing a state of but- 
tons in the TltleMenu in response to operations from a 
user, and branch commands for branching in response 
to confirmation operations made for buttons. The branch 
commands realize branching to individual Titles. 
[021 9] These MOVIE objects relating to the menus al- 
low to realize menu behavior such as that realized in a 
DVD. Thus concludes the description of MOVIE objects 



relating to menu controls. 

[0220] Next are described improvements in the Index 
Table according to the fourth embodiment. A FirstPlay 
Index, an AudioMenu Index, a SubtitleMenu Index, and 
s a TltleMenu Index are added to the Index Table of the 
present embodiment. As described in the first embodi- 
ment, these indexes are referred to by dynamic scenar- 
ios of any of three modes. 

[0221] The FirstPlay Index is referred to during 
BD-ROM startup. The filename of the FirstPlay object is 
described in this Index. 

[0222] The TopMenu Index, AudioMenu Index, Subti- 
tleMenu Index, and TltleMenu Index are referred to 
when user operations are conducted to directly call the 
Audio Menu, Subtitle Menu, and Title Menu, respective- 
ly. A direct call by a user is conducted by the user push- 
ing down an Audio select key, a Subtitle select key, or a 
Title select key on a remote controller. 
[0223] Thus concludes the description of improve- 
ments in MOVIE objects according to the present em- 
bodiment. Next are described improvements in a play- 
back device of the present embodiment. In order to op- 
erate MOVIE objects as described above, the module 
manager 20 needs to perform processing procedures 
shown in a flowchart of FIG. 48. 
[0224] In order to conduct menu controls, the module 
manager 20 of the present embodiment performs 
branch controls according to the processing procedures 
shown in FIG. 48. This flowchart differs in that Step S24 
has been inserted between Steps S8 and S11 , and the 
module manager 20 performs processing of Steps S25 
to S28 before returning to Step S4 if Step S24 is YES. 
Steps S25 to S28 involve setting a scenario for conduct- 
ing menu controls as the current dynamic scenario. That 
is, if a branch destination of the branch command is xxx- 
Menu (Step S24: YES), the module manager 20 sus- 
pends the current dynamic scenario i, saves variable x 
(Step S25), retrieves a filename from an Index corre- 
sponding to the branch-destination menu (Step S26), 
sets the dynamic scenario of the retrieved filename as 
the current dynamic scenario / (Step S27), and returns 
the current mode to the MOVIE mode (Step S28). After 
that, the module manager 20 proceeds to execute the 
current dynamic scenario. 

[0225] According to the present embodiment as de- 
scribed above, since branching to dynamic scenarios for 
menu controls is realized with indirect referencing via 
the Indexes of the Index Table, it Is possible to branch 
to dynamic scenarios for menu controls, even when a 
menu key is pushed during execution of the Java mode 
or the Browser mode. Audio and subtitle switching from 
a Java Virtual Machine or from the Browser mode is 
made possible. Thus, even when playback is performed 
using a Java Virtual Machine or in the Browser mode, 
the present embodiment is capable of audio and subtitle 
switching similar to normal DVDs. 
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5. Fifth Embodiment 

[0226] In the first embodiment, application programs 
in the Java mode describe playback controls targeted 
for a BD-ROM using programming functions and system s 
variables supplied from the playback control engine. 
That is, programming functions and system variables 
supplied from the playback control engine are directly 
used for describing playback controls. On the other 
hand, applications in the Java mode according to a fifth 10 
embodiment describe controls targeted for a BD-ROM 
via member functions supplied by the Java module 1 7. 
[0227] Explanation of the kind of member functions 
playback controls being described is in reference to FIG. 
49. FIG. 49 shows member functions of classes belong- is 
ing to the Java mode. The Java mode, which is Layer 
4, has a BD-ROM only package containing classes of 
BD-ROMStatus, BD-ROMReproduction, and BD-ROM- 
Event. 

[0228] The following gives an account of individual 20 
classes in the package. 

[0229] The BD-ROM Event class includes multiple 
member functions including a setEventListener func- 
tion. The setEventListener function makes, when an in- 
stance of ZZZ.CLASS (a Java object) is generated, a 25 
declaration on the use of member functions of the Java 
object. That is, the use of member functions of the Java 
object becomes possible only after the declaration of 
use by the setEventListener function is made. When 
TimeEvents and UserEvents occur, event handlers 30 
whose use has been declared by the setEventListener 
function are driven. 

[0230] The BD-ROMReproduction class is a class 
packaging PlayPL at CELL(), PlayPL at Mark(), and 
PtayPL at Specified Time() as member functions. 35 
[0231 ] The BD-ROMStatus class is a class of member 
functions for status acquisition and status setting. 
Namely, this is a class packaging, as memberf unctions, 
(i) Get value of Player Status Register function, (ii) Set 
value of Player Status Register function, (iii) Get value *o 
of General Purpose Register function, and (iv) Get value 
of General Purpose Register function shown in the first 
embodiment. 

[0232] The arrows yd , yc2, yc3, yc4, and yc5 in the 
figure schematically show a PL playback function and 
acquisition/setting of register setting values via member 
functions of the BD-ROMStatus class, BD-ROMRepro- 
duction class, and BD-ROM Event class. As shown by 
these arrows, the Java object of the fifth embodiment 
applies programming functions supplied by the play- so 
back control engine 12 and player variables which are 
register setting values via the package in the Java mod- 
ule^. 

[0233] FIG. 50 shows controls via member functions 
in the Java mode. 55 
[0234] The arrow yp1 symbolically depicts a genera- 
tion of a Java object, which is an instance of ZZZ. 
CLASS. This generation is made by the Java module 1 7 



when branching to the Java object is instructed for the 
first time. The arrow yp2 symbolically depicts a call of 
the setEventListener function by the Java object. 
[0235] The arrow yh1 symbolically shows a declara- 
tion on the use of event handlers made by the 
setEventListenerfunction in the event object. The arrow 
yh2 symbolically shows an event handler driven by a 
member function in the event object. That is, event han- 
dlers of Java objects are made available in response to 
the declaration on the use of event handlers made from 
the member function (setEventListner function) in the 
event object, and are driven by UserEvents and 
TimeEvents defined by ClipMarks and PLMarks. 
[0236] The arrow yh3 symbolically shows status ac- 
quisition by a driven event handler. Namely, event han- 
dlers, which are member functions of Java objects ac- 
cording to the fifth embodiment, indirectly implement 
status acquisition and setting of a playback device using 
a member function (get System Parameter Register) of 
a class belonging to the Java mode. 
[0237] The arrow yh4 symbolically shows PL play- 
back by a driven event handler. Namely, event handlers, 
which are member functions of Java objects, instruct a 
playback device to perform PL playback using a mem- 
ber function of the BD-ROMReproduction class. 
[0238] According to the present embodiment as de- 
scribed above, since playback controls targeted for a 
BD-ROM is described via a package in the Java module 
17, it is possible to describe the playback controls tar- 
geted for a BD-ROM in the same style as general Java 
language programming style. This allows to enhance 
production efficiency of software houses that have en- 
tered producing movie works. 
[0239] Note that it is desirable that the package of the 
present embodiment is issued by an organization in 
charge of license management of the BD-ROM stand- 
ardization under the condition that the organization en- 
ters into an official contract with software houses devel- 
oping application programs. The contract includes a 
prohibition provision of not developing application pro- 
grams discreditable to movie works recorded on 
BD-ROMs. Herewith, it is possible to have software 
houses develop various applications while curbing the 
fear of dishonoring movie works. 

6. Sixth Embodiment 

[0240] In the first to fifth embodiments, MOVIEobjects 
perform transitions from the MOVIE mode to the Java 
mode based on branch commands in the Navigation 
Button information. Here in a sixth embodiment, transi- 
tions from the MOVIE mode to the Java mode are per- 
formed via a menu. FIG. 51 shows a menu hierarchy 
according to the sixth embodiment. This differs from the 
menu hierarchy images shown in FIG. 46 in that a tran- 
sition to the Extra Menu from the Top Menu is made pos- 
sible. The Extra Menu, which receives a selection be- 
tween the Java mode and the Browser mode from a us- 
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er, includes a button for receiving a transition to the Java 
mode and a button for receiving a transition to the 
Browser mode. FIG. 52 shows MOVIE objects and an 
Index Table according to the sixth embodiment. The fig- 
ure differs from FIG. 47 in that (1) there is an ExtraMenu 5 
object (ExtraMenu OBJ) that controls the behavior of the 
Extra Menu, and it is possible to perform branching from 
the MOVIE object in the TopMenu to this ExtraMenu ob- 
ject, and (2) there is an Index for the Extra Menu within 
the Index Table, and it is possible to perform branching 10 
to the ExtraMenu object by a push down of a menu key 
on a remote controller. 

[0241] A transition to the Java mode is performed in 
response to a push down of the menu key, and this 
means that the transition to the Java mode is performed 1$ 
irrespective of the current playback point. This is also 
the case with a transition to the Browser mode. 
[0242] Thus concludes the description of the improve- 
ments in the MOVIE objects and the Index Table accord- 
ing to the present embodiment. Next are described im- 20 
provements in Java objects of the sixth embodiment. 
The Java object according to the present embodiment 
finds that, at a transition from the MOVIE mode to the 
Java mode, branching to the Java mode has been per- 
formed from which playback point in the MOVIE mode 25 
by referring to SPRM(10). Then, the Java object con- 
ducts processing in the Java mode with referring to 
SPRM(1 0) and a pre-equipped schedule table (FIG. 53). 
The schedule table shows correspondence between 
characters appearing in the video data and time slots in 30 
which the characters are appearing. 
[0243] The Java objects refer to the table to find char- 
acters) at the current playback point, and execute a 
game starring the character(s). 

[0244] According to the present embodiment as de- 35 
scribed above, branching via the menu allows a transi- 
tion from the MOVIE mode to the Java mode. In addition, 
by referring to SPRM(1 0) that indicates a playback point 
immediately before the branch, processing can be 
switched according to a point where a user has finished *o 
watching. Such switching enables producing Java lan- 
guage applications that closely relate to the playback of 
movie works. 

7. Seventh Embodiment 

[0245] In the first embodiment, PL shearing is made 
possible where a CELL in the PL played in the MOVIE 
mode is played also in the Java mode. However, the 
sharing poses an impediment in the case of setting fil- so 
tering information in PL information. The filtering infor- 
mation specifies, from among a plurality of streams mul- 
tiplexed on the AV stream, which streams are valid and 
invalid. The reason of setting the filtering information is 
described below. The AV stream Includes, in addition to 55 
video and audio streams, streams such as Navigation 
Button information and subtitle streams. The Navigation 
Button information is necessary for the MOVIE mode, 



but it is not always the case with the Java and Browser 
modes. This is because, in the Java mode, CGs can be 
rendered using the Java language, and there is no need 
to employ the Navigation Button information. In order to 
treat the Navigation Button information as invalid in the 
Java mode, such filtering information is required. How- 
ever, if the filtering information is set in PL information 
and the above-cited PL sharing is performed, the filter- 
ing information that specifies stream validity and inva- 
lidity is also shared. 

[0246] When filtering information is set in PL informa- 
tion, a PL is set as shown in FIG. 54 in the present em- 
bodiment since shearing of PL information is undesira- 
ble. FIG. 54 shows a configuration of PL information ac- 
cording to a seventh embodiment. Filtering information 
and APR Flag have been added to the PL information in 
the figure. 

[0247] APR Flag is information for specifying that dy- 
namic scenarios in which mode are allowed to use the 
PL. A specification of an application program is made 
by selecting one of three modes of the MOVIE mode, 
Java mode, and Browser mode. Any MOVIE object is 
able to use the PL information when APP.Flag indicates 
"00:MOVIE mode", but Java objects and WebPage ob- 
jects are not able to use the PL information. 
[0248] On the other hand, any Java object is able to 
extract the PL information when APP.Flag indicates "01 : 
Java mode". When APP.Flag indicates "10:Browser 
mode", any WebPage object is able to extract the PL 
information. Further more, when APP.Flag indicates 
"11", dynamic scenarios in any mode can apply the PL 
information. 

[0249] APP.Flag enables realizing exclusive controls 
where dynamic scenarios of one mode are allowed to 
use one piece of PL information while dynamic scenar- 
ios of other modes are not allowed to use the piece. 
Such exclusive controls achieve filtering information set 
in the PL information being used by dynamic scenarios 
in a mode intended to be used, and avoid playing 
streams in unintended modes. 
[0250] Setting PL information enables sharing as 
shown in FIG. 55. FIG. 55 shows hierarchical sharing 
where each piece of PL information is exclusively used 
by the MOVIE mode or the Java mode while the digital 
stream is shared by the MOVIE and Java modes. 
[0251] To perform processing based on APP.Flag, a 
dynamic scenario according to the present embodiment 
receives APP.Flag of a desired PL for playbackfrom the 
playback control engine 12 prior to a PlayPL function 
call. The dynamic scenario judges whether or not the 
mode to which the dynamic scenario belongs is coincid- 
ed with the mode shown in the received APP.Flag. If 
these modes are the same, then the dynamic scenario 
performs a PlayPL function call. On the other hand, if 
they disagree, the function call is not performed. As a 
result that the dynamic scenario and the playback con- 
trol engine 12 implement the above processing, only a 
dynamic scenario in the mode indicated in APP.Flag 
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performs playback of the PL. 
[0252] Note that, at a time of a PlayPL function call, 
the dynamic scenario may inform the playback control 
engine 12 of a mode to which the dynamic scenario be- 
longs, and the playback control engine 12 may judge 
whether the mode is coincided with a mode indicated in 
APR Flag of a function-call destination PL. Then, the 
PlayPL function is executed if they are coincided, and 
the PlayPL function is not executed if they disagree. 
Herewith, only a dynamic scenario in the mode indicated 
in APP.Flag performs playback of the PL. 
[0253] A hierarchical sharing as shown in the present 
embodiment enables scene extraction in which, for ex- 
ample, one scene in the MOVIE mode is used in the 
Java mode with the use of filtering information. 
[0254] It is not to be argued that filtering information 
and APP.Flag can be set in stream management infor- 
mation. However, any sharing of an AV stream among 
modes becomes impossible if filtering information is set 
in stream management information, and therefore this 
is not well advised. In order to realize the use in other 
modes, it is preferable to leave a means for sharing of 
an actual AV stream by setting APP.Flag and filtering 
information in PL information. 

8. Eighth Embodiment 

[0255] The present embodiment relates to BD-ROM 
production processes. FIG. 56 is a flowchart showing 
BD-ROM production processes according to an eighth 
embodiment. 

[0256] The BD-ROM production processes include a 
material producing process S101 for creating materials 
such as video records and audio records, an authoring 
process S1 02 for generating an application format with 
the use of an authoring device, and a pressing process 
S103 for creating a master BD-ROM and pressing and 
laminating to complete BD-ROMs. 
[0257] Of these processes, the authoring process tar- 
geting the BD-ROM comprises five processes: a sce- 
nario editing process S201 ; a material encoding process 
S202; a multiplexing process S203; a formatting proc- 
ess S204; and an emulation process S205. 
[0258] The scenario editing process S201 is for con- 
verting an outline created in the planning stage into a 
format comprehensible to a playback device. The sce- 
nario editing results are created as BD-ROM scenarios. 
In addition, multiplexing parameters for realizing multi- 
plexing are also created in the scenario editing. 
[0259] The material encoding process S202 is an op- 
eration for respectively encoding video materials, audio 
materials, and subtitle materials to obtain a video 
stream, audio streams, and subtitle streams. 
[0260] The multiplexing process S203 interleave-mul- 
tiplexes the video stream, audio streams, and subtitle 
streams obtained as a result of the material encoding, 
and the result is converted into a single digital stream. 
[0261] In the formatting process S204, various types 



of information are created based on BD-ROM-oriented 
scenarios, and the scenarios and digital stream are 
adapted to a BD-ROM format. 
[0262] The emulation process S205 is for confirming 
5 whether or not the authoring result is correct. 

[0263] Since Java objects and WebPage objects can 
be respectively described using the Java and markup 
languages in the scenario editing process above, it is 
possible to develop these objects with the same sensi- 
10 bility as that applied in the development of general com- 
puter-oriented software. Accordingly, the present em- 
bodiment has the effect of increasing the efficiency of 
scenario creation. 

9. Ninth Embodiment 

[0264] A ninth embodiment is an embodiment for im- 
plementing the recording medium according to the 
present invention as a rewritable optical disc such as a 
BD-RE (Blu-ray Rewritable disc). The data configuration 
of "an AV stream, stream management information, and 
PL information" shown in the first embodiment Is com- 
patible with BD-REs. A BD-RE recording apparatus 
writes the data configuration of "an AV stream, stream 
management information, and PL information" to 
BD-REs by conducting real-time recording of broadcast- 
ing signals. A user performs programming with respect 
to the BD-REs on which the data configuration has been 
written, describes MOVIE objects, Java objects, Web- 
Page objects, and an Index Table, and writes these to 
the BD-REs. Herewith, a similarformatto the application 
format shown in the first embodiment can be realized 
on BD-REs. 

[0265] The present embodiment described above of- 
fers an opportunity for a user having a BD-RE recording 
apparatus to create the application format shown in the 
first embodiment, and therefore, it is possible to let many 
users know the pleasure of creating movie works shown 
in the first embodiment. 

10. Tenth Embodiment 

[0266] A tenth embodiment relates to locking a play- 
back device into core system behavior under certain 
conditions, even if the playback device is operable to 
operate Java objects and WebPage objects. 
[0267] That is, under the following situations (1) to (7), 
a path for transferring from the MOVIE mode to the en- 
hanced modes is closed: 

(1) when an encryption key for protecting a copy- 
right of a movie work is exposed in a playback de- 
vice, and the a playback device is made invalid by 
a key management center; 

(2) when there is a possibility that copies of a movie 
work will be circulated on networks as a result that 
a user made unauthorized copies of the movie work 
recorded on a recording medium by using ripper 
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software; 

(3) when additional charge is not paid although it is 
required for execution of the enhanced modes; 

(4) when it is desired to cut a playback device off 
from a network due to an occurrence of a failure in s 
a system of the playback device; 

(5) when there are version conflicts in Java Virtual 
Machines and browsers; 

(6) when there is a possibility of leakage of personal 
information or infection with virus software, and it is u> 
desired to cut a playback device off from a network; 
and 

(7) when it is desired to cut a playback device off 
from a network in order to protect movie works on 

a recording medium from an unauthorized device is 
attempting to read recorded contents on the record- 
ing medium via a network. 

[0268] Java objects and WebPage objects according 
to the present embodiment have a check routine for 20 
checking the existence of the above situations (1) to (7). 
The check routine conducts checks on a playback de- 
vice for installation of unauthorized software and virus 
infections in cooperation with a server on a network. The 
server is operated by, for example, an encryption key 2s 
management center for managing the use of encryption 
keys by playback devices, an accounting center for 
charging users, and a copyright management center 
that promotes detection of illegal copies. Java and Web- 
Page objects perform communication with these cent- 30 
ers. The Java and WebPage objects have been pro- 
grammed so as to forcibly transform a playback device 
to behave as a core system when the playback device 
meets at least one of the situations (1 ) to (7). 
[0269] Here, checks on a possibility of illegal copies 35 
with the use of ripper software can be realized by incor- 
porating a check routine in Java objects and WebPage 
objects, the check routine can be realized with process- 
ing of reporting files and folders in HDs to a center on a 
regular basis and having those censored by the center. 40 
Note that such censoring assumes advance approval 
on the purchase of movie works. 
[0270] The present embodiment as described above 
enables, while realizing an added value enhancement 
via a network, to describe Java objects and WebPage <s 
objects so as to set a playback device into core system 
behavior and then use the playback device in a stand- 
alone configuration, in the case when copyright holders 
and playback-device manufacturers desire to discon- 
nect a network connection of the playback device for so 
some reason. In particular, the present embodiment has 
significance in the case where HDs and operating sys- 
tems have been installed on the playback device, and 
BD-ROMs are used in a playback environment similar 
to a personal computer. Note that, the playback device 55 
may be transformed back to a full system if appropriate 
measures are implemented after the occurrence of a sit- 
uation as cited above. 



1 1. Eleventh Embodiment 

[0271] An eleventh embodiment relates to a playback 
device equipped with a HD, and the communication unit 
23 of the playback device downloads an Index Table and 
new PL's and writes these to the HD. When a new Index 
Table is written to the HD, in the event of branching from 
a PL to another PL, the module manager 20 retrieves a 
filename not from the Index Table recorded on a 
BD-ROM but from the Index Table recorded on the HD, 
instead. Then, the module manager 20 reads video data 
having the retrieved filename, and has the DVD-like 
module 1 6, the Java module 1 7, orthe BROWSER mod- 
ule 18 execute the video data. 
[0272] The present embodiment described above en- 
ables a playback device to download an Index Table and 
replacement videos in the case when certain PLs re- 
corded on a BD-ROM have moral and ethical issues. As 
a result, it is possible to have a user watch replacement 
videos, instead of the problematic videos, by causing 
the playback device to make indirect referencing via the 
new Index Table during the playback. Since there is no 
need to rewrite ail the dynamic scenarios recorded on 
a BD-ROM when partial replacement is desired, the 
present embodiment is capable of avoiding the risk of 
recalling the recording medium even when such prob- 
lems are raised. 

[0273] In addition to the case where replacing videos 
is wanted, when it is desired not to have playback de- 
vices play certain Titles from among multiple Titles re- 
corded on BD-ROMs, or when it is desired to shuffle the 
order of Titles recorded on BD-ROMs, all is required is 
to download an Index Table. This is because there is no 
need to rewrite dynamic scenarios recorded on 
BD-ROMs in order to make these modifications. 

12. Remarks 

[0274] Thus have been described the present inven- 
tion based on the embodiments above, however, these 
embodiments are provided as mere examples of sys- 
tems which are expected to bring about the best effects 
under the present set of circumstances. The present in- 
vention can be modified without departing from the 
scope of the invention. The following items (A) to (W) 
are representative modifications of the present inven- 
tion. 

(A) In all the embodiments above, an optical disk 
according to the present invention is implemented 
as a BD-ROM. However, the optical disk of the 
present invention is characterized by the recorded 
dynamic scenarios and Index Table, and these 
characteristics are not dependent on the physical 
properties of a BD-ROM. Any form of recording me- 
dia is applicable as long as there exists the capacity 
to record dynamic scenarios and Index Tables. For 
example, optical disks such as DVD-ROM, 
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DVD-RAM, DVD-RW, DVD-R, DVD+RW, DVD+R, 
CD-R, and CD-RW, and optical-magnetic disks 
such as PD and MO are ail applicable. Semicon- 
ductor memory cards such as compact flash cards, 
smart media, memory sticks, multimedia cards, and s 
PCM-CIA cards are also applicable. Furthermore, 
(i) magnetic recording disks such as flexible disks, 
SuperDisk, Zip, and Clikl, and (ii) removable hard 
disk drives such as ORB, Jaz, SparQ, SyJet, EZF- 
ley, and microdrives are applicable. In addition, the 10 
recording medium may also be a built-in hard disk. 

Dynamic scenarios, Index Tables, and PL infor- 
mation may be recorded on a different recording 
medium from one for the AV stream and stream 
management information. These may then be read is 
in parallel and played as a single video edit 

(B) Although the playback devices in all the embod- 
iments first decode AV streams recorded on a 
BD-ROM and then output the result to a TV, the 
playback device may be structured only from a 20 
BD-ROM drive, and all of the other elements are 
equipped on a TV. In this case, the playback device 
and the TV can be incorporated into a home net- 
work connected using IEEE1394. In addition; al- 
though the playback devices in the embodiments 25 
are of a type used after connecting to a TV, integral 
display-playback devices are also applicable. Fur- 
thermore, the playback device may be only those 
parts of the playback devices of the embodiments 
that perform essential parts of the processing. Be- 30 
cause these playback devices are all inventions dis- 
closed in the specification of the present applica- 
tion, acts involving the manufacture of playback de- 
vices based on an internal structure of the playback 
devices shown in the first to eleventh embodiments 35 
are implementations of the inventions disclosed in 

the specification of the present application. Acts 
that involve transferring (retail when cost is in- 
volved; a gift when no cost is involved), lending, or 
importing of playback devices shown in the first to *o 
eleventh embodiments are also implementations of 
the present invention. Acts that involve approaching 
the general user about transfer and rental by means 
of show-widow displays, catalogue solicitation, 
pamphlet distribution and the like are also imple- 45 
mentations of these playback devices. 

(C) Because of the information processing by pro- 
grams shown in FIGs. 29-31, FIG. 39, and FIG. 48 
being realized specifically using hardware resourc- 
es, programs showing the processing procedures so 
in the flowcharts form an invention in their own right. 
Although all of the embodiments show embodi- 
ments that relate to the implementation of programs 
relating to the present invention in an incorporated 
form in the playback devices, the programs shown 55 
in the first to eleventh embodiments may be imple- 
mented in their own right, separate from the play- 
back devices. The implementation of the programs 



in there own right includes acts that involve: (1) pro- 
duction of the programs; (2) transference of the pro- 
grams, either gratuitous or otherwise; (3) lending of 
the programs; (4) importing of the programs; (5) 
providing the programs publicly via bi-directional 
electronic communications circuits; and (6) ap- 
proaching the general user about transfer and rent- 
al by means of show-widow displays, catalogue so- 
licitation, pamphlet distribution, and so forth. 

(D) Consider that the element of "time" relating to 
the steps executed in time-series in the flowcharts 
of FIGs. 29-31 , FIG. 39, and FIG, 48 is a required 
item for specifying the invention. If this is the case, 
then the processing procedures shown by the flow- 
charts can be understood as disclosing the usage 
configurations of the playback method. Execution 
of the processing in the flowcharts so as to achieve 
the original objects of the present invention and to 
enact the actions and effects by performing the 
processing of the steps in time-series is, needless 
to say, an implementation of the recording method 
pertaining to the present invention. 

(E) Although Java objects in the above embodi- 
ments are applications that render CGs, any appli- 
cation described in the Java language is applicable. 
For example, Java objects may be client applica- 
tions used for EC (Electronic Commerce). Because 
Java objects that provide descriptions of products 
involving videos of movie works can be realized, it 
is possible to bring character business pertaining to 
movie works to a success. In addition, applications 
of Java objects may be online fighting games. Fur- 
thermore, characters represented by CGs using 
Java objects may perform processing as an agent. 
Characters as agents may realize a help function of 
playback devices, or may supply advices to a user. 

A library as used by Java objects may be re- 
corded on BD-ROMs. Such a library includes PNG 
files, MNG files storing animation data, XML files 
storing information relating to streams, and HTML/ 
SMIL files. Particularly, in the case where MNG files 
storing animation data are recorded on BD-ROMs 
as a library, it is possible to readily render a CG of 
an owl as described above. 

Information that WebPage objects retrieve from 
websites may be web pages, and image data. In 
addition, such information may be AV streams, 
stream management information, and PL informa- 
tion. WebPage objects may conduct processing in 
cooperation with search engines. 

Furthermore, description languages in the en- 
hanced modes may be C++, C#, and the like. 

(F) Note that an example in FIG. 18 of the first em- 
bodiment is a mere example of a technique for de- 
scribing playback controls of the BD-ROM accord- 
ing to the present invention. Other description tech- 
niques include directly branching from Navigation 
Button information in an AV stream to a Java object. 
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FIG. 57 shows an example of a playback control for 
branching directly from Navigation Button informa- 
tion in an Av stream to a Java object. Describing 
Navigation Button information so as to perform such 
branching allows unrestricted descriptions of scene s 
development, such as branching from a scene in 
which a character appears to a game starring the 
character, which expands the range of expression 
for scene development. 

(G) Regarding the sixth embodiment, a menu 10 
(Chapter Menu) for displaying a list of Chapters and 
MOVIE objects for controlling the behavior of the 
menu may be recorded on a BD-ROM so that 
branching from the Top Menu is made possible. In 
addition, the menu may be called by pushing down 15 
a Chapter key on a remote controller. 

(H) At recording on a BD-ROM, extension headers 
preferably are appended to TS packets structuring 
an AV stream. The extension headers, which are 
called TP_extra_header, include an 20 
"Arrival_Time_Stamp" and a 
"copyjDermission ^indicator", and have a 4-byte da- 
ta length. TP_extra_header-attached TS packets 
(hereinafter, abbreviated to "EX-attached TS pack- 
et") are arranged into groups of 32 packets, and 25 
written into three sectors. Each group comprising 

32 EX-attached TS packets is 6,144 bytes in length 
(=32x192), and matches the 6,144-byte size of 
three sectors (=2048x3). The grouping of 32 EX- 
attached TS packets contained in three sectors is 30 
referred to as an "Aligned Unit". 

The playback device 200 transmits Aligned 
Units in transmission processing as described be- 
low, when used in a home network connected via 
IEEE1 394. That is, a device on the side of the send- 35 
er removes the TP_extra_header from each of the 
32 EX-attached TS packets included in an Aligned 
Unit, and outputs the TS packets after encoding the 
TS packet body based on a DTCP standard. When 
outputting TS packets, isochronous packets are in- *o 
serted between all adjacent TS packets. The posi- 
tioning of isochronous packets is based on times 
shown in the Amvai_Time_Stamp in each 
TP_extra_header. The playback device 200 outputs 
a DTCP_Descriptor following the outputting of the 45 
TS packets. The DTCP_Descriptor shows a copy 
permissibility setting in each TP_extra_header. 
Here, if the DTCP_Descriptor is described so as to 
show "copy prohibited", TS packets will not be re- 
corded on other devices when used in a home net- so 
work connected via IEEE1394, 

(I) Copy generation information (CGI) may be em- 
bedded in AV streams, and limited copies of AV 
streams may be permitted. CGI includes "copy free" 
indicating unrestricted copies permitted, "one gen- 55 
eration cop/ 1 indicating that recording of one gen- 
eration copy is permitted, "no more copy" indicating 
that reproduction of a further copy is prohibited, and 



"never copy" indicating that copying is by no means 
permitted. That is, a backup from HD to DVD is per- 
formed only when CGI embedded in the contents 
shows "copy free" or "one generation copy", but a 
backup is not performed when CGI shows "no more 
copy" or "never copy". 

(J) In the case where rights management informa- 
tion is added to AV streams, copy of AV streams 
may be allowed under use conditions defined in 
rights management information. 

When conditions for copy permits are defined 
with the specified number of copies in rights man- 
agement information, copying is performed within 
this scope. When conditions for copy permits are 
defined with a specified period of validity (year, 
month, and day), copying is performed within this 
scope. 

(K) In the case when copy processing includes var- 
iations such as transfer, migration, check-out, and 
the like, a backup may be performed based on de- 
fined use conditions with respect to each variation. 
Transfer is copy processing involving deletion of 
contents at a copy source, and is used when con- 
tents are transferred among multiple recording me- 
dia. 

Migration is copy processing conducted on the 
premise that information on use conditions is creat- 
ed at a recording medium of a copy destination. 

Check-out is a type of copy with the limited 
number of copies, and copy of contents is imple- 
mented after the number of copies is decremented. 
Check-out differs from commonly termed "copy with 
limited number" in that an increment in the number 
of copying is possible. An increment in the number 
of copying is conducted after processing of making 
impossible to play contents recorded on the record- 
ing medium, due to copying (this is called "check- 
In"). 

(L) AV streams in the above embodiments may be 
VOBs (Video Objects) complying with a DVD-Video 
standard or a DVD-Video Recording standard. 
VOBs are program streams compliant with ISO/ 
I EC1 381 8-1 obtained by multiplexing video and au- 
dio streams. In addition, AV streams in the embod- 
iments may be called "AVCIips". In this case, stream 
management information is called Clip information. 
Also, video streams in the AV streams may be an 
MPEG-4 format, WMV format, or the like. Further- 
more, audio streams may be a Linear-PCM format, 
Dolby-AC3 format, MP3 format, or MPEG-AAC for- 
mat. 

(M) Although Cell information in the above embod- 
iments specifies a start and end of a playback sec- 
tion using time information, logical addresses on a 
BD-ROM can be used instead. In addition, CELL in 
the above embodiments may be called "Playltem". 
(N) TMAP in stream management information may 
be called "EP_map". In this case, playback start 
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times of ACCESS UNITs are preferably represented 
by time-stamps (Presentation Time Stamp) of pic- 
ture data located at the head of individual ACCESS 
UNITs. In addition, addresses of ACCESS UNITs 
are preferably represented by serial numbers of s 
PES packets (SPN (Serial Packet Number)). 
(0) In the structure of the playback devices, only the 
current dynamic scenario is stored in dynamic sce- 
nario memory 15 and only the current stream man- 
agement information and the current PL information 10 
are stored in the static scenario memory 11 . How- 
ever, a plurality of scenarios, stream management 
information, and PL information may be stored in 
advance, as with cache memory. Herewith, the time 
lag until reading this data from the BD-ROM can be 15 
shortened. In addition, although BACKUP memory 
14 saves the stored values of registers in stack 
form, when consideration is given to the relationship 
with memory size, it is realistic to arrange the stored 
values for saving on the one level. 20 
(P) In order to play two or more CELLs structuring 
a PL in a row, it is preferable that a process has 
been conducted so as to join these CELLs seam- 
lessly. 

A process for a seamless join can be realized 25 
by copying an end part of a preceding playback sec- 
tion and a head part of a foliow-on playback section 
of the video data to create a copied portion in ad- 
vance, and re-encoding the copied portion. Note 
that the copied portion created for a seamless join 30 
may be called a "Bridge-Clip". 

Here, it is preferable to set the end part and 
head part as follows. 

The end part is preferably composed of an AC- 
CESS UNIT including an Out-point of the preceding 35 
playback section and two ACCESS UNITS in front 
of the Out-point including ACCESS UNIT within a 
preceding CELL information #x. On the other hand, 
the head part is composed of an ACCESS UNIT in- 
cluding an In-point of the follow-on playback section 40 
within the following CELL information #x+1 . The 
ground for setting the end and head parts in this way 
is described in the related technology of U.S. Patent 
Publication No. 6148,140 disclosed by the appli- 
cants of the present invention, and therefore for *5 
more detail refer to the patent publication. 

Furthermore, ft is desirable to set seamless join 
information for the copied portion created for a 
seamless join. Seamless join information includes 
a playback starting time of the first video frame, a so 
playback ending time of the last video frame, an au- 
dio gap starting time, an audio gap duration, and 
audio gap location information. When such seam- 
less join information has been defined, it is possible 
to calculate the difference in time stamps (STC-Off- 55 
set) of the two sections using the playback starting 
time of the first video frame and the playback ending 
time of the last video frame, and set the calculated 



difference to a playback device. In addition, control- 
ling an audio decoder by referring to the audio gap 
information allows to prevent audio discontinuity at 
the time of a transition from one section to another. 
(Q) Titles (movie works) in the above embodiments 
corresponds to all copyrighted works expressed in 
video pictures, such as TV films, game software, 
and the like. This is because video edits in the 
above embodiment (i) are expressed in a method 
that produces visual or audio-visual effects, such as 
cathode-ray tube display, liquid crystal display, and 
the like; (ii) exist as maintaining the identity by being 
tied with BD-ROMs, which are tangible entities, in 
one way or another; and (iii) are placed in a repr- 
oducible situation, and thus satisfy requirements as 
formats for existence of movie works with a copy- 
right. 

However, since essential elements of the 
present invention are not limited to such video edits, 
video data of the present invention may be video 
pictures obtained by monitoring cameras and home 
video cameras. 

(R) BD-ROMs in the above embodiment are equiv- 
alent to HD-DVDs and BD-ROMs described in the 
priority applications on which a claim of priority is 
based (U.S. No. 60/409,999 and No. 60/440,623). 
In addition, playback control engines 12 in the 
above embodiments correspond to a BD-ROM-FF 
processor 3025 and a scenario processor 304 (FIG. 
35) disclosed in the specification of the basic appli- 
cation. The module manager 20 corresponds to a 
playback controller 3024 (FIG, 35) while the DVD- 
like module 16, the Java module 17, and the 
BROWSER module 18 correspond to a DVD com- 
patible module 3021, a Java module 3023, and a 
browser module 3022. Since these are described in 
the basic application, the priority claims related to 
the technical matters are justified. 
(S) CGs rendered in the Java language (e.g. the im- 
age of an owl) may be created with data in the 
NURBS format (Non Uniform Rational B-Spline). 
NURBS is a bundle of Bezier curves (such a bundle 
of Bezier curves is called "B-spline"), and the cur- 
vature of each Bezier curve is not uniform. 

CGs may be created in a polygon format. The 
polygon format is a data format that is defined to 
represent certain three-dimensional shape by poly- 
hedral approximation. AutoCAD's Data exchange 
Format (DXF) defined by Autodesk in the U.S. and 
other formats of HRC, WAVE FRONT, IV, and VRML 
are widely known polygon formats. 

Surface patterns of configurations may be add- 
ed by texture mapping. The rendering engine 22 
creates projected images of three-dimensional 
shape data described above, and has an image de- 
coder decode the projected images. At this point, 
the rendering engine 22 performs texture mapping. 
Texture mapping is a process of pasting texture pat- 
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terns, such as a still image, a bitmaps, and the like, 
on a plane surface or a curved surface to display 
the result. In addition, colors and brightness of 
plane surfaces between control points are calculat- 
ed based on distances and positional relationship s 
between a light source position and plane surfaces 
of individual pieces of the three-dimensional shape 
data, and colors and brightness of projected images 
on screen are adjusted according to the calculated 
brightness. This process of calculating colors and io 
brightness of plane surfaces between control points 
based on distances and positional relationship be- 
tween a light source position and each plane sur- 
face is called shading process. As a result of the 
shading process, projected images of three-dimen- '5 
sional shape data are shaded, and obtain three-di- 
mensional appearances. The processing described 
above enables to display CGs comparable to those 
created by specialized game machines, next to vid- 
eo images of a movie. 20 

Motions of characters, such as the flight of an 
owl, are realized by altering the three-dimensional 
shape data based on a constant regularity. It is pref- 
erable to record the three-dimensional shape data 
between extents structuring XXX.M2TS (positions 25 
corresponding to "another files" in FIG. 7). Here- 
with, the AV stream and three-dimensional shape 
data can be read all together. 
(T) Although, in the above embodiments, user's se- 
lection operations for video edits are received from 30 
a remote controller, the operations may be received 
from a front-panel of a playback device. Alternative- 
ly, user specifications can be received via input de- 
vices, such as a keyboard, a touch panel, a mouse, 
a pad, a trackball, and the like. In such cases, the 35 
selection operations may be received through click 
and drag operations. 

(U) Movie edits in the embodiments may be ob- 
tained by encoding analog video signals broadcast 
by analog broadcast. Also, the movie edits may be 40 
stream data constituted from transport streams 
broadcast by digital broadcast. 

In addition, contents may be obtained by en- 
coding analog/digital video signals recorded on vid- 
eotape. Furthermore, contents may be obtained by 45 
encoding analog/digital video signals taken directly 
from a video camera. Alternatively, contents may be 
digital copyrighted works distributed from distribu- 
tion servers. 

(V) The Java module 1 7 may be a Java platform so 
installed in a device in order to receive satellite 
broadcasts. If the Java module 17 is this Java plat- 
form, a playback device according to the present 
invention shares processing as MHP-use STBs. 

Furthermore, the Java module 17 may be a 55 
Java platform installed in a device in order to per- 
form mobile telephone processing controls. If the 
Java module 1 7 is this Java platform, a playback 



device according to the present invention shares 
processing as a mobile telephone. 

In addition, the BROWSER module 18 may be 
computer-installed Browser software such as Mi- 
crosoft's Internet Explorer, and the like. 
(W) In the layer model shown in FIG. 12, the Brows- 
er mode and the MOVIE mode may be disposed 
over the Java mode. Particularly because of the 
light burden, on the playback device, of the inter- 
pretation of dynamic scenarios and the execution 
of control procedures based on dynamic scenarios 
in the MOVIE mode, no problems arise even when 
the MOVIE mode is executed over the Java mode. 
In addition, when developing playback devices and 
movie works, operation assurance can be dealt with 
in a single mode. 

[0275] Furthermore, the Java mode processing may 
be executed only in the Java mode, instead of three 
modes being provided. As shown in the second embod- 
iment, since playback controls synchronized with PL 
playback are possible even in the Java mode, the ne- 
cessity of providing the MOVIE mode is removed. Fur- 
thermore, controls of dynamic scenarios may be per- 
formed only in either the MOVIE mode or the Browser 
mode. 

Industrial Applicability 

[0276] Since a recording medium according to the 
present invention effectively enhances the added value 
of video data structuring movie works, it is possible to 
supply 



Claims 

1. A recording medium having video data, a plurality 
of programs, and a table recorded thereon, wherein 

each of the plurality of programs shows a 
playback control procedure of the video data, 

the table includes (1) identification informa- 
tion of each of the plurality of programs, and (2) in- 
formation showing that each of the plurality of pro- 
grams belongs to either a movie mode or an en- 
hanced mode, 

one of the plurality of programs includes a 
command for branching, and 

the branching command specifies a branch 
destination using indirect referencing via the table. 

2. The recording medium of Claim 1 , wherein 

the table includes a plurality of indexes corre- 
sponding one-to-one with the plurality of programs, 

the indexes show that the plurality of corre- 
sponding programs respectively belong to either 
the movie mode or the enhanced mode, and 

the indirect referencing is to specify a program 
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of the branch destination by using labels relating to 
the indexes. 

3. The recording medium of Claim 2, wherein 

the indexes include a reserved index, and 
the reserved index corresponds to a movie- 
mode program used alternatively to an enhanced- 
mode program when branching to the enhanced- 
mode program is instructed in a playback device op- 
erable to execute only the movie mode. 

4. The recording medium of Claim 1 , wherein 

a movie-mode program and an enhanced- 
mode program are executed by two or more execu- 
tion modules, 

the two or more execution modules are resi- 
dent programs on a same layer in a control hierar- 
chy, and 

the playback control procedure is described 
using a function supplied from the control hierarchy 
layer. 

5. The recording medium of Claim 4, wherein 

the supplied function is one of (1) a function 
for having a playback device execute a playback 
control based on a predefined playback path, (2) a 
function for setting a predetermined value to a reg- 
ister in the playback device, and (3) a function for 
acquiring the value set to the register. 

6. The recording medium of Claim 5, wherein 

the branching is to branch from the movie- 
mode program to the enhanced-mode program, 

the playback control procedure performed by 
the movie-mode program is to set the predeter- 
mined value to the register, and 

the playback control procedure performed by 
the enhanced-mode program is a process conduct- 
ed with reference to the predetermined value. 

7. The recording medium of Claim 6, wherein 

the value set to the register is a value showing 
one of (1) an audio setting in the playback device, 
(2) a subtitle setting in the playback device, (3) an 
angle setting in the playback device, (4) a currently 
played title, (5) a currently played chapter, and (6) 
a current playback point. 

8. The recording medium of Claim 5, having pieces of 
playlist information recorded thereon, wherein 

each piece of the playlist information defines 
a playback path by arranging pieces of information 
showing playback sections in the video data ac- 
cording to a playback order, and 

the playback control executed with the sup- 
plied function is based on the playback path defined 
by each piece of the playlist information. 



9. The recording medium of Claim 8, wherein 

each of the plurality of programs includes a 
function call for calling the supplied function for ex- 
ecuting the playback control, 
s the function call includes two arguments, 

of the two arguments, a first argument speci- 
fies a piece of the playlist information, and 

a second argument specifies a starting point 
in the playback path. 

10 

10. The recording medium of Claim 9, wherein 

the starting point is specified using one of a 
playback section, a playback time, and a chapter. 

'5 11. The recording medium of Claim 8, wherein 

each piece of the playlist information has a 
flag attached thereto, 

the flag shows that video data playback using 
the piece of the playlist information to which the flag 
20 js attached is allowed either in the movie mode or 
in the enhanced mode. 

12. The recording medium of Claim 8, wherein 

the branching is to branch from the movie- 
25 mode program to the enhanced-mode program, 

the playback control procedure performed by 
the movie-mode program is to specify a starting 
point in the playback path defined by a piece of the 
playback information for playback execution, and 
30 the playback control procedure performed by 

the enhanced-mode program is to specify the start- 
ing point in the playback path defined by the same 
piece of the playback information for playback exe- 
cution. 

35 

13. The recording medium of Claim 1 , wherein 

the enhanced mode is a mode for having a 
virtual machine execute a program, and 

an enhanced-mode program is described in a 
40 virtual machine-oriented programming language. 

14. The recording medium of Claim 13, wherein 

in the enhanced-mode program, an execution 
of the playback control procedure is triggered by an 
45 event that occurs in a playback device during play- 
back of the video data. 



15. The recording medium pf Claim 14, wherein 

the event is one of (1) an event showing that 
a current playback position has reached a predeter- 
mined time point on a playback time axis of the vid- 
eo data, and (2) an event showing that the current 
playback position has proceeded by a predeter- 
mined time interval on the playback time axis. 
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16. The recording medium of Claim 15, having mark in- 
formation recorded thereon, wherein 

the mark information defines the predeter- 
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mined time point and the predetermined time inter- 
val. 

17. The recording medium of Claim 14, wherein 

the event shows that a user operation has 
been performed during a predetermined time period 
on a playback time axis of the video data. 

18. The recording medium of Claim 17, wherein 

the user operation shows that fast-forwarding, 
rewinding, or pausing has been instructed during 
playback of the video data. 

19. The recording medium of Claim 13, wherein a mov- 
ie-mode program includes a button command, 

the button command is a command for 
branching to the enhanced-mode program, and is 
recorded on the recording medium as a multiplexed 
stream after being multiplexed with the video data 
and subtitle data, and 

each piece of the subtitle data is image data 
of a button, and the button command is executed 
when a confirmation operation is conducted with re- 
spect to the image data of the button. 

20. The recording medium of Claim 1 , wherein 

the enhanced mode is a mode for having a 
browser execute a program, and 

an enhanced-mode program is described in a 
markup language. 

21. The recording medium of Claim 20, wherein 

a movie-mode program includes a button 
command, 

the button command is a command for 
branching to the enhanced-mode program, and is 
recorded on the recording medium as a multiplexed 
stream after being multiplexed with the video data 
and subtitle data, and 

each piece of the subtitle data is image data 
of a button, and the button command is executed 
when a confirmation operation is conducted with re- 
spect to the image data of the button. 

22. The recording medium of Claim 1 , wherein 

the enhanced mode includes a virtual-ma- 
chine mode for having a virtual machine execute 
one or more of the enhanced-mode programs and 
a browser mode for having a browser execute one 
or more of the enhanced-mode programs, and 

the branching is to branch between a program 
in the virtual-machine mode and a program in the 
browser mode. 

23. A playback device relating to a recording medium 
having video data, a plurality of programs, and a ta- 
ble including indexes pertaining to the respective 
plurality of programs recorded thereon, comprising: 



a plurality of modules operable to execute the 
respective plurality of programs, the plurality of 
modules including a module corresponding to 
a movie mode and a module corresponding to 
s an enhanced mode; and 

a manager operable to control branching be- 
tween the plurality of programs, wherein 
the table is information showing that each of the 
plurality of programs belongs to either a movie 
10 mode or an enhanced mode, 

the branching is described, for each of the plu- 
rality of programs, using indirect referencing via 
the table, and 

the manager decides, at a time of the branch- 
15 ing, a module for executing a program of a 

branch destination by referring to the table. 

24. The playback device of Claim 23, wherein 

the indexes included in the table correspond 
20 one-to-one with the plurality of programs, 

the indexes show that the plurality of corre- 
sponding programs respectively belong to either 
the movie mode or the enhanced mode, and 

the indirect referencing is to specify the pro- 
25 gram of the branch destination by using labels re- 
lating to the indexes. 

25. The playback device of Claim 24, wherein 

the decision by the manager is made by iden- 
30 tifying an index to which the label is allocated and 
by judging the identified index belongs to either the 
enhanced mode or the movie mode. 

26. The playback device of Claim 25, wherein 

35 in a case where a program execution by the 

enhanced-mode corresponding module is impossi- 
ble, the manager has the movie-mode correspond- 
ing module execute an alternative movie-mode pro- 
gram, even if the label is allocated to an index be- 
40 longing to the enhanced mode, 

the table includes a reserved index, and 
the alternative movie-mode program corre- 
sponds to the reserved index. 

45 27. The playback device of Claim 23, further compris- 
ing: 

a register; and 

a playback control engine operable to perform 
so a functional operation in response to a function 

call from each of the movie-mode and the en- 
hanced-mode corresponding modules, where- 
in 

the functional operation is one of (1 ) receiving 
55 a value from one of the modules and setting the 

value to the register, (2) acquiring the value 
from the register and passing the value over to 
one of the modules, and (3) playing the video 
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data according to a predetermined playback 
path. 

28. The playback device of Claim 27, wherein 

the branching is to branch from a movie-mode 
program to an enhanced-mode program, 

a playback control procedure performed by 
the movie-mode program is to have the playback 
control engine set the value to the register, and 

the playback control procedure performed by 
the enhanced-mode program is to have the play- 
back control engine read the value to the register. 

29. The playback device of Claim 28, wherein 

the value set to the register is a value showing 
one of (1) an audio setting in the playback device, 
(2) a subtitle setting in the playback device, (3) an 
angle setting in the playback device, (4) a currently 
played title, (5) a currently played chapter, and (6) 
a current playback point. 



34. The playback device of Claim 31 , wherein 

the branching is to branch from the movie- 
mode program to the enhanced-mode program, 
the playback control procedure performed by 
5 the movie-mode program is to specify the starting 
point and have the playback control engine perform 
playback, and 

the playback control procedure performed by 
the enhanced-mode program is to specify the same 
10 starting point in the playback path and have the 
playback control engine perform playback. 

35. The playback device of Claim 23, wherein 

the movie-mode corresponding module has a 
*5 virtual machine, and 

an enhanced-mode program is described in a 
virtual machine-oriented programming language. 

36. The playback device of Claim 35, further compris- 
20 ing: 



a playback control engine operable to perform 
a functional operation in response to a function 
call from each of the movie-mode and the en- 
hanced-mode corresponding modules, where- 
in 

the playback control engine causes an occur- 
rence of an event synchronized with video data 
playback, 

the enhanced-mode program includes an event 
handler, and 

the enhanced-mode corresponding module ex- 
ecutes the event handler when the playback 
control engine causes the event occurrence. 



30. The playback device of Claim 28, wherein 

pieces of playlist information are recorded on 
the recording medium, 

each piece of the playlist information defines 
a playback path by arranging pieces of information 
showing playback sections in the video data ac- 
cording to a playback order, and 

a playback control executed by the playback 
control engine is based on the defined playback 
path. 

31. The playback device of Claim 30, wherein 

each of the plurality of programs includes a 
function call for calling the functional capability of 
playing the video data performed by the playback 
control engine, 

the function call includes two arguments, 

of the two arguments, a first argument speci- 
fies a piece of the playlist information, and 40 

a second argument specifies a starting point 
in the playback path. 



37. The playback device of Claim 36, wherein 

the event is one of (1 ) an event showing that 
a current playback position has reached a predeter- 
mined time point on a playback time axis of the vid- 
eo data, and (2) an event showing that the current 
playback position has proceeded by a predeter- 
mined time interval on the playback time axis. 



32. The playback device of Claim 31 , wherein 

the starting point is specified using one of a 45 
playback section, a playback time, and a chapter. 

33. The playback device of Claim 31 , wherein 

each piece of the playlist information has a 
flag attached thereto, so 

the flag shows that video data playback using 
the piece of the playlist information to which the flag 
is attached is allowed either in the movie mode or 
in the enhanced mode, and 

the playback control engine performs the 55 
playback control based on the piece of the playlist 
information at a time when the mode shown by the 
flag is being executed. 



38. The playback device of Claim 37, wherein 

mark information is recorded on the recording 
medium, 

the mark information defines the predeter- 
mined time point and the predetermined time inter- 
vat, and 

the event occurrence is caused based on the 
mark information. 

39. The playback device of Claim 36, further compris- 
ing: 

a receiving unit operable to receive a user op- 
eration, wherein 

the event shows that the receiving unit has re- 



36 



69 



EP 1 551 027 A1 



70 



ceived the user operation during a predeter- 
mined time period on a playback time axis of 
the video data. 

40. The playback device of Claim 39, wherein 5 

the user operation includes fast-forwarding, 
rewinding, and pausing during the video data play- 
back. 

41. The playback device of Claim 35, comprising: io 

a demultiplexer operable to demultiplex a mul- 
tiplex stream to obtain a button command, the 
video data, subtitle data; 

an image decoder operable to decode im- 15 
age data of a button; and 

a video decoder operable to decode the 
video data, wherein 

a movie-mode program includes the but- 
ton command, 20 

the button command is a command for 
branching to the enhanced-mode program, and 
is recorded on the recording medium as the 
multiplex stream after being multiplexed with 
the video data and the subtitle data, 25 

each piece of the subtitle data is the im- 
age data, and 

the movie-mode corresponding module exe- 
cutes the button command when a confirmation 
operation is conducted with respect to the im- 30 
age data. 

42. The playback device of Claim 23, wherein 

the enhanced mode is a mode for having a 
browser execute a program, and 35 

an enhanced-mode program is described in a 
markup language. 

43. The playback device of Claim 42, comprising: 

40 

a demultiplexer operable to demultiplex a mul- 
tiplex stream to obtain a button command, the 
video data, subtitle data; 
an Image decoder operable to decode image 
data of a button; and 45 
a video decoder operable to decode the video 
data, wherein 

a movie-mode program includes the but- 
ton command, 

the button command is a command for so 
branching to the enhanced-mode program, and 
is recorded on the recording medium as the 
multiplex stream after being multiplexed with 
the video data and the subtitle data, 

each piece of the subtitle data is the im- 55 
age data, and 

the movie-mode corresponding module exe- 
cutes the button command when a confirmation 



operation is conducted with respect to the im- 
age data. 

44. The playback device of Claim 23, wherein 

the enhanced mode includes a virtual-ma- 
chine mode for having a virtual machine execute 
one or more of the enhanced-mode programs and 
a browser mode for having a browser execute one 
or more of the enhanced-mode programs, and 

the branching is to branch between a program 
in the virtual machine mode and a program in the 
browser mode. 

45. A playback processing program relating to a record- 
ing medium having video data, a plurality of pro- 
grams, a table including indexes pertaining to the 
respective programs recorded thereon, comprising 
the following processing: 

having a computer perform a plurality of execu- 
tion steps in each of which one of the plurality 
of programs is executed, and a control step for 
controlling branching between the plurality of 
programs, the plurality of execution steps in- 
cluding an execution step corresponding to a 
movie mode and an execution step corre- 
sponding to an enhanced mode, wherein 
the table is information showing that each of the 
plurality of programs belongs to either a movie 
mode or an enhanced mode, 
the branching is described, for each of the plu- 
rality of programs, using indirect referencing via 
the table, and 

the control step is a step for deciding, at a time 
of the branching, an execution step for execut- 
ing a program of a branch destination by refer- 
ring to the table. 

46. A playback method relating to a recording medium 
having video data, a plurality of programs, a table 
including indexes pertaining to the respective pro- 
grams recorded thereon, comprising the following 
steps: 

a plurality of execution steps in each of which 
one of the plurality of programs is executed, the 
plurality of execution steps including an execu- 
tion step corresponding to a movie mode and 
an execution step corresponding to an en- 
hanced mode; and 

a control step for controlling branching between 
the plurality of programs, wherein 
the table is information showing that each of the 
plurality of programs belongs to either a movie 
mode or an enhanced mode, 
the branching is described, for each of the plu- 
rality of programs, using indirect referencing via 
the table, and 
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the control step is a step for deciding, at a time 
of the branching, an execution step for execut- 
ing a program of a branch destination by refer- 
ring to the table. 

5 

47. A recording method of a recording medium, com- 
prising the following steps: 

creating application data; and 
recording the created application data on the 10 
recording medium, wherein 
the application data includes video data, a plu- 
rality of programs, and a table, 
each of the plurality of programs shows a play- 
back control procedure of the video data, 15 
the table includes (1 ) identification information 
of each of the plurality of programs, and (2) in- 
formation showing that each of the plurality of 
programs belongs to either a movie mode or an 
enhanced mode, 20 
one of the plurality of programs includes a com- 
mand for branching, and 
the branching command specifies a branch 
destination using indirect referencing via the ta- 
ble. 25 
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FIG 15 



PL INFORMATION 



STREAM MANAGEMENT INFORMATION 




©SELECT CHARACTER A 
©SELECT CHARACTER B 
©SELECT CHARACTER C 



MENU 



WHEN CHARACTER A 
SELECTED 
GPRM(0)-1 
WHEN CHARACTER B 
SELECTED 
GPRM(0)-2 
WHEN CHARACTER C 
SELECTED 
GPRM(0)-3 



Navigation Button INFORMATION 
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FIG16 



DYNAMIC SCENARIO IN MOVIE MODE 
MOVIE OBJECT(M-OBJ) 

PRE-COMMAND POST-COMMAND 



GPRM(0)«-0 



Play 
PL 

COMMAND 



IF(GPRM(0)=0) 
Ump Title #m| 
else 

{Jmp Title #m+l) 



] 



PL INFORMATION 



STREAM MANAGEMENT INFORMATION 




©SELECT CHARACTER A 
©SELECT CHARACTER B 
©SELECT CHARACTER C 



MENU 



WHEN CHARACTER 
A SELECTED 
GPRM(0)-1 

WHEN CHARACTER 
B SELECTED 
GPRM(0)-2 

WHEN CHARACTER 
C SELECTED 
GPRM(0)*-3 



Navigation Button INFORMATION 
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FIG 17 



Java OBJECT(J-OBJ) 



IF(GPRM(0)==1) 

{ A.draw Character ();PlayPL(PL#1 ,CELL#2);} 
else { if (GPRM(0)==2) 

{ B.draw Character();PlayPL(PL#2,CELL#l );}} 
else { if (GPRM(0)==3) 

{ C.draw Character();PlayPL(PL#1 ,CELL#3);}}} 
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FIG.39 (EXECUTION PROCEDURE OF PLPlay FUNCTION) 
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